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ABSTRACT 


The problem of detecting process deadlocks is common to 
transaction oriented computer systems which allow data sharing. 
Several good algorithms exist for detecting process deadlocks in 
a single location facility. However, the deadlock detection 
problem becomes more complex in a geographically distributed 
computer network due to the fact that all the information needed 
to detect a deadlock is not necessarily available in a single 
node, and communications delays may lead to synchronization 
problems in getting an accurate view of the network state. 


In this Thesis, two published algorithms dealing with 
deadlock detection in computer networks are discussed, and exam- 
ples demonstrating the failure of these algorithms are given. 
Two algorithms are then presented for detecting deadlocks in a 
computer network which allows processes to wait for 1) access to 
a portion of a database, or 2) a message from another process. 
The first algorithm presented is based on the premise that there 
is one control node in the network, and this node has primary 
responsibility for detecting process deadlocks. The second, and 
recommended, algorithm distributes the responsibility for 
detecting deadlocks among the nodes in which the involved pro- 
cesses and resources reside. Thus a failure of any single node 
has limited effect upon the other nodes in the network. A com- 
puter model of the "decentralized" (second) algorithm was de- 
signed and it is described in the Thesis. 
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I. Introduction 

A simple example of deadlock (or "deadly embrace") occurs 
when a process P1 is blocked while waiting for access to resource 
R2 which is controlled by process P2, and P2 in turn is blocked 
while waiting for access to resource R1 which is controlled by 
P1. A deadlock may involve more than two processes. For exam- 
ple, process P1 may be waiting for access to resource R2 which is 
controlled by process P2, P2 may be waiting for access to 
resource R3 which is controlled by process P3, ..., process 
P{n-1] may be waiting for access to resource Rn which is con- 
trolled by process Pn, and Pn may be waiting for access to 
resource R1 which is controlled by P1. 

Multiprocessing and data sharing are commonly used in a 
single location transaction oriented computer system. In the 
future they will be common to transaction oriented, geographi- 
cally distributed computer networks. In this Thesis an algorithm 
is presented that can be used to detect deadlocks involving pro- 
cesses waiting for access to a shared portion of a database or 
waiting for a message from a process with which it is 
communicating within a computer network. It is possible that a 
process can be either computerized or manual, although a manual 
process (i.e. a person at a terminal) can not directly request 
access to a portion of a database, as it is restricted to only 
communicate with computerized processes by the use of messages. 
Throughout this paper, the word "operator" will be used to refer 


to a manual process. 


Much has been written dealing with deadlock detection, 
avoidance and prevention in computer aystens. However, most of 
the literature discusses a single location facility where the 
status of all processes and resources are aveilabie in a single 
local table. (For a good discussion, including a graph model of 
computer systems which can be used to detect deadlocks, see "Some 
Deadlock Properties of Computer Systems" {7].) Very few articles 
have been published that are concerned with the deadlock problem 
in a computer network (geographically distributed computer 
system). 

When dealing with a computer network as opposed to a single 
location facility, the deadlock detection problem becones more 
difficult due to the fact that all the information needed to de- 
tect a deadiock is not necesserily availabie in a single node, 
and communication delays may lead to synchronization problems in 
getting an accurate view of the network state. Some reasons for 
restricting access to portions of a database (even though the 
result of blocking processes can lead to deadlock) and some rea- 
sons why the common deadlock prevention end avoidance algorithms 
are not well suited to the networks under consideration will be. 
discussed. Several deadlock detection schemes for computer net- 
works (some from recent literature, some designed by this author) 
will be presented, and they will be followed by a discussion of 


some of the benefits of using the various schemes. _ 


I.1 The Interference Problem 

Given two or more independent processes, interference is 
said to have occurred if the results produced by their concurrent 
execution would not have been obtained by running these processes 
one at a time in any order (i.e. nonconcurrently). 

A simple example of interference is the following. Let two 
processes, P1 and P2, read the contents of database record R1. 
Then let P1 add 5 to the value and let P2 add 10 to the same 
value. Now let each process alter the contents of R1 to contain 
the value computed by that process. Depending upon the order of 
update, the contents of R1 will be either 5 or 10 greater than 
the value that was contained during the reads. We have a case of 
interference because the value of R1 would have been 15 greater 
than the value contained at the time of the first read if P1 and 
P2 had been executed sequentially in either order. 

Another case of interference occurs when a process, in pro- 
cessing one transaction, twice alters the contents of the same 
database object and in between the two writes, a second process 
reads the contents of that database object. In some cases a 
process which is only reading the contents of a database object 
may not care if there is any interference, in which case it may 
request "dirty read" access to the database object. (A process 
that is only reading the contents of a database object can not 
interfere with the values produced by another process, although 
other processes can interfere with the values produced by the 


"reading" process.) 


When maximum concurrency among independent processes is de- 
Sired, a process must be allowed to read and alter the contents 
of a database object whenever it wants to. (This type of access 
to data has been called "shared reed/shared urite".) In order to 
detect interference, records must be kept about the type of use 
(read or write) of each database object, and what processes (and 
when they) used it. Am algorithm to detect interference when 
this information is kept is presented in "On Managing Interfer- 
ence Caused by Database Sharing” [10]. A more thorough discus- 
sion of interference 1s also given. After an interference 
situation is detected, at least one of the involved processes 
must be forced to rollback te a previous state in order to cor- 
rect the interference condition. 

Most systems, in order to avoid interference and guarantee 
that a process will see a consistent state of a database, 
restrict access to data by a system of locks. If a process wants 
to change the contents of a database object, it must request ex- 
clusive access to that database object, thus temporarily (for the 
duration of the lock) preventing al} other processes from 
accessing that database object. If a process only wants to read 
the contents of a database object, it can request shared read 
access to that database object, thus temporarily (for the dura-~ 
tion of the lock) preventing all other processes from altering 
the contents of that database object. If a database object can 
be shared among several readers, the method of access is called 


"shared read/exclusive write", whereas if there can be only one 


reader, it is called "exclusive read/exclusive write". 

When a request for access to a database object (resource) 
can not be granted due to the existence of a lock on that 
database object, the requesting process must be blocked until the 
resource becomes available. Due to processes waiting for access 
to resources, there exists the possibility of deadlock among the 


processes in a computer system. 


I.2 Deadlock Prevention 

Deadlock prevention schemes place constraints upon system 
users in order to ensure that deadlock will never occur. There 
is little operating system overhead involved when using 
prevention methods. There are several deadlock prevention algo- 
rithms that are widely known: 

1. Each process must request all needed resources at one 
time and will remain blocked until all requests can be 
granted simultaneously. (This is often referred to as 
"static" allocation.) 

2. All resources are given a unique number and processes 
must request resources, one at a time, in numerical or- 
der. 

3. When an active process requests a resource that is con- 
trolled by a blocked process, the blocked process must 
release the resource so that it may be allocated to the 
active process. A process will go from the active to 
blocked state only if it requests a resource controlled 
by another active process. 

The unpredictability of resource usage in a transaction 

oriented system, plus the loss of productivity that results from 
tying up resources unnecessarily or forcing processes to release 


resources and request them later (which often results in some 


redundant computations due to a process having to repeat some 
operations to maintain a consistent database) make prevention 
algorithms undesirable for use in the syerens. under considera- 
tion. In a multiprocessing environment whioh considers 
inter-process messages as resources, it is taposaibie to have an 
advance knowledge of all the resources that pipes be needed by a 
process. Thus algorithm 1 can not be used in this type of sys- 
tem, whether it is a single or mult4 node facility. Algorithm 2 
is unsuitable for the systems under consideration because al- 
though it may be possible to give e wniqué number to each 
inter-process message, a process must be "#llocated" each message 
that it will send te another process, which can result in many 
difficulties when two processes are sending sevéral messages to 
each other. Algorithm 3 can not be used WeGadse it implies that 
all resources must be pre-emptable (tf. e. they must be ‘able to be 
héieased by a process upon the demand of the - system), which is an 


impossible situation when messages are treated as resources. 


T3 Deadlock Avoidance 

Deadlock avoidance algorithms caiculate safe paths for com- 
pletion of all processes. Before a resource is allocated to a 
given process, the. operating systen cheeks id there would be at 
least one path via which all processes can run bs completion 
after the allocation is made. If no such path exists, then the 
requesting process must wait until a time when the resource can 


be safely allocated to the process. Avoidance algorithms thus 
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force processes to wait jineewsaarity in order to be certain that 
all processes will be able to run to completion without eis 
threat of deadlock. | 

In "System Deadlocks" [5] it is stated that "to avoid 
deadlocks in a multiprogramming system in which the necessary 
conditions for deadlocks can exist, it is ieualive necessary to 
have some advance information on the pencuree issce of tasks." 
When portions of databases are considered resources, and they are 
locked at a level lower than a file (page, record, field, etc.), 
it is difficult to determine in advance what database objects 
will be needed. In addition, due to the unpredictability of 
processes in a transaction oriented system, it is impossibre to 
have an advance knowledge of all the inter-process messages that 
will be requested by a process. Therefore, deadlock avoidance 
algorithms can not be used in a single or multi node transaction 


system which permits inter-process communication. 


I.4 Deadlock Detection 

Since it. seems that deadlock prevention and avoidance algo- 
rithms are unsuitable for the distributed systems under consid- 
eration, deadlock detection methods must. be examined. When 
employing a deadlock detection algorithm, requested resources are 
usually assigned to the requesting processes whenever possible, 
and processes are blocked only when desired resources are 
unavailable. Either the operating system or a system user must 


occasionally check for a deadlock situation, and if one is found, 


11 


must rollback (backup) and retry at least ene process in order to 
break the deadlock. «at is hoped this will force a new sequence 
of access to resources.) | 

From the tonlermentor’s viewpoint. the easiest strategy to 
adopt is that shore one assumes deadlock occurs infrequently. In 
this case someone (Can operates) external to the network would 
have the responsibility for detecting the deadlock and deciding 
what process aheute be forced to rollback to a previous state. 
With this approach the only overhead involves the temporary 
inability to access the resources controlled by the deadlocked 
processes and the cost of rollbaek/retry of sone. (or all) of the 
deadlocked processes. (This cost may be large for each deadlock, 
but if there are few deadlocks the overall system cost may be 
less than it would be if there were a "deadlock detector" that 
was constantly checking for deadlocks.) One could also assume 
that if a POE ss: has been blocked for "x" units of time, then it 
is deadlocked and the operating system should force it to 
rollback to a previous state, although this strategy may result 
in some unnecessary redundant computations because Some processes 
that will be retried may not have been involved in a deadlock. 

At least two articles have been published which propose 
protocols for allocating database objects in a computer network 
in a manner such that deadlock car be detected at the time a 
request for access is dented. In designing an algorithm to be 
used to detect process deadlocks tn & transaction oriented com- 


puter network which allows process to process ‘communication, it 
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is necessary to allow for the possibility of a process waiting 
for a message from another process (which may be manual or 
computerized). Additionally, a process must be allowed to wait 
for access to a database object which has been allocated to at 
least one other process. 

Any algorithm that will be implemented as part of an oper- 
ating system should be as efficient as possible. Therefore, in 
the algorithms proposed by this author, an attempt was made to 
minimize the number and size of internodal messages involved in 


the detection of deadlocks. 


1.5 Structure of the Thesis 

Chapters II and III contain descriptions and comments 
(including some examples pointing out deficiencies) relating to 
two papers that have been published proposing protocols for 
allocating database objects in a computer network such that 
deadlock can be detected at the time a request for access to a 
database object is denied. Chapter IV presents an introduction 
to the two schemes for detecting deadlock in a computer network 
that are proposed by this author in Chapters V and VI. The two 
schemes differ in that one (Chapter V) places the primary re- 
sponsibility for detecting deadlock anywhere in the network on 
one control node, whereas the other totally distributes the re- 
sponsibility throughout the network. Chapter VII contains a 
discussion of a functional model of the algorithm proposed in 


Chapter VI. The Appendices contain a description and demonstra- 


13 


tion of the model, in addition to containing the PL/I code for 
the model itself. Chapter VIII contains sone sueesttors for 
future research, and Chapter IX contains a comparison of the 
various algorithms presented in Chapters It, III, Vv and VI, plus 
some concluding remarks. | 

If one only wants to read about the algorithm that is 
recommended by this author, it is possible to read Chapters IV 
and VI with no loss of understanding. Chapter VII can also be 
understood after reading Chapters IV and VI; as can the Appendi- 


ces and some portions of Chapter VIII. 


14 


‘ II. Proposal of Chandra, Howe and Karp 
In "Communication Protocol for Deadlock Detection in Com- 
puter Networks" [3], a scheme is presented which the authors call 
"a novel solution to the deadlock problem in the network 
environment." Their "solution" is described below, and the de- 
scription is followed by an example where the scheme allows a 


deadlock to go undetected. 


II.1 Chandra, Howe and Karp's Proposed Solution 

The authors propose that each installation (node) maintain a 
resource table (RT) which contains information about which pro- 
cesses have been allocated local resources, which processes have 
been queued (waiting for access) for local resources, which local 
processes have been allocated remote resources and which local 
processes have been queuved for remote resources. The type of 
access requested by each process is also recorded. The authors 
claim that in a single node facility, there are several well 
known algorithms for detecting deadlocks using the tables 
mentioned above. They then state "it is believed to be obvious 
that these same algorithms would suffice in the multiple instal- 
lation case provided that the resource table were to be expanded 
to include the pertinent information from the remote sites." A 
scheme to expand the resource table in a node is given in the 
paper. 

The authors believe there are three types of requests for 


resources that can lead to deadlock. (In all cases, "it is as- 
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sumed that the requested resource is not available, because, if 
it were, the allocation would take place immediately.") The ac- 
tion taken for each type of request is the following (as stated 
in the paper): 

Case 1 


A process requests a local resource, which is allocated 
to a local process, and all of the processes which are 
queued for this resource are also local processes. All of 
the necessary information is contained in the local RT, and 
the request is resolved locally. 


Case 2 


A process requests a local resource, which is either 
allocated to a remote process or one or more of the pro- 
cesses that are queued for thts resource are remote 
processes. In this case, all of the RT's must be obtained 
by the local installation since deadlock may occur. Once 
all of the RT's have been obtained, the 
deadlock-determination algorithm can be applied to the 
expanded RT which contains all of the resources and pro- 
cesses in the total community of installations. 


Case 3 


A process requests a resource at some remote installa- 
tion. In this case, the requesting installation forwards 
the request and its RT to the installation which has the 
requested resource. This installation then determines if 
the request can be honored immediately or if all of the RT's 
must be first obtained. In the case where the requested 
resource is allocated to or queued by only processes local 
to the two involved systems, the request can be honored im- 
mediately. Otherwise, this installation obtains the RT's 
from the remaining installations and then resolves the 
request. 


In all of these cases, the RT's that are involved in 
the decision procedure must be locked until after the deci- 
sion has been made. If the decision involves the RT's of 
the other installations in the community, these installa- 
tions must be notified after the decision is made and their 
table is then released. In Case 3, the updates to the RT 
must be returned to the requesting installation while all 
other tables can he discarded and a simple release notice 
returned. 
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A description is given of the actions to be taken when "two 
or more installations may simultaneously request the various RT's 
in order to make an allocation for two or more independent 


requests." 


II.2 A Fault in the Proposed Solution 
There are some resource requests which fall under Case 1, 
and result in a deadlock for which the local RT does not contain 


enough information to detect. Consider the following example: 


Let the network consist of two nodes, A and B. Let 
processes P1 and P2 and resource R1 be local to A, and let 
processes P3 and P4 and resources R2, R3, and R4 be local to 
B. Assume the following state of the network. (Figure 
II.1a contains a diagram of this "intermediate" state.) P1 
has exclusive control of R1 and is queued waiting for access 
to R4, P2 has exclusive control of R2 and is queued waiting 
for access to R1, P3 has exclusive control of R3 and is 
queued waiting for access to R2, and P4 is active 
(non=-blocked) and has exclusive control of R4. In this 
State there is no deadlock. Now let P4 request access to R3 
and be queued for the resource. A deadlock now exists (see 
Figure II.1b) involving all four processes and all four 
resources. With the tables as described in the article, 
this deadlock could not be detected unless node A sent node 
B its tables, but this does not take place because the 


request falls into Case 1 (since P4 is local to B, as are P3 
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and R3). Therefore the deadlock goes undetected. 


Similar examples (for networks consisting of three or more 
nodes) exist where requests falling under Case 3 result in 
undetected deadlocks. RT's from 3 or more nodes may be needed 
even if "the requested resource is allocated to or queued by only 


processes local to the two involved" nodes. 
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Intermediate State Diagram 


Figure II. 1a 
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Figure II.1b 
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III. Proposals of Mahmoud and Riordon 

In "Protoeol Considerations for Software Controlled Access 
Methods in Distributed Data Bases" [8], bus sehemes are presented 
for allocating database files in a network environment. The 
authors (Professors at Carleton University, Ottawa, Ontario, 
Canada) claim that with their schemes, by using the graphic rep- 
resentation as described in [9], deadlocks-ean be detected at the 
time an allocation decision is made. The two schemes are de- 
scribed below, and a brief discussion about the schemes follows, 
including an example where one of the proposals allows a deadlock 
to go undetected. 

The first approach described requires that all deadlock 
tests be made by one node, whereas with the second: approach each 
node must test for deadlock resulting from-different processes 
accessing its files. Each node in the network will contain a 
Distributed Pata Rase Management Facility (DDBMF) which will 
communicate with the other DDBMF processes in: the network for the 


purpose of Handling requests for local and remote processes. 


III.1 Mahmoud and Riordon's Centralized Control Approach 

In the centralized approach, one node, called the control 
node, will make all the deadlock tests and handle all file 
allocations. If a process running at node i would like access to 
a file in node j, a request is sent to the DBBMF tn node i, which 
then relays it to the central - DDBMF even if:node 1 and node j 


are the same. Since the central DDBMF makes all the file 
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allocation decisions, it has an overall picture of the global 
network status, and can therefore decide if the request can 


safely (without deadlock) be placed on the file queue. 


III.2 Mahmoud and Riordon's Distributed Control Approach 

In the distributed approach, the DDBMF at each node will 
have full control over all access to the files located at its 
node. As a result of this, the authors state that “each node 
DDBMF will be responsible for handling job interference 
(deadlock) problems that may arise while different processes are 
accessing its files." In order to avoid or detect deadlocks 
involving processes and files located at two or more nodes, "each 
individual DDBMF must obtain information from other DDBMF pro- 
cesses indicating the status of their files and queue tables. 
The information will be used ... to construct a global picture of 
the network and thus enable each individual DDBMF process to make 
the correct decisions." 

All active user processes are separated into two classes. 
In the authors’ own words, 

The classification is based on the localities of the files 

requested by the process and the type of access to each of 

these files: 

Class 1: each process belonging to this class has the fol- 

lowing properties: 

1) All files accessed by the process during its active 
session are located in a single node. 

2) All files being updated by the process are single-copy 
files in the network (i.e. only a single copy of each 
file exists in the network). 

Class 2: each user process belonging to this class has the 
following properties: 


1) Files that are accessed simultaneously by the process 
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during an active session do not all exist in a single 
computer system and/or 

2) Any one of the files being updated by the process has 
multiple copies in the network. 


It is obvious that the two classes of processes are 
mutually exclusive. 


The authors suggest using a graph representation in order to 
detect deadlock, and they describe how a DDBMF gets information 
from the other DDBMF's in the network and when it should check 
for deadlock: 


Assume that there are n nodes in the network, i.e., n 
individual DDBMF processes. Each process will transmit 
(n-1) identica). messages simultaneously, with one message 
addressed to each of the remaining DDBMF processes. Each 
message contains the most updated iaforwation: about the 
status and queues of files at the node in question. The 
messages will be transmitted periodically. at the onset: of. 
synchronous clock intervals. Siallarly, each DDBMF process 
will receive periodically (n-}) messages. fromthe other 
processes. Wow assume that a DDBMF process receives a 
request for access to,one.of the files under its control 
from a local or remote user process. If the! requesting 
process belongs to class 1, the DDBMF.will respond immedi- 
ately to the request. Otherwise the DDBMF will delay action 
until the next time interval,.i.e., until. receiving updated 
information about the status of the network files from other 
DDBMF processes. The request is then cheeked against any 
possible interference (deadlock) and the user process is 
notified once a deaision is made. . Penal 


Requests which can not be acted uporm until the next time 
interval are placed in a pre-test. queue, ro YE. 


‘At the beginning of a clock interval, each processor 
receives information from other processors including the 
contents of the file queves and the prertest queue. The 
processor extracts the contents of the pre-test queues and 
combines them to, canstruct a global pretest queue which 
includes all the requests for. file access received by all 
processors during the previous tine interval. The file ac- 
cess requesta on the global pre-test. queve are tested for 
deadlock conditions and decisions ere. then made 


To avoid deadlock situations. caused i epitivat race 
conditions, the file access pequests on: the global. pre-test 


| 
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queue must be arranged in the same order in all 

processors... All processors must then follow a predefined 

routine in constructing the global pre-test queue. The 
resulting versions of the global pre-test queue will be 
identical in all processors at the beginning of every clock 
interval. 

III.3 Some Comments about the Proposed Schemes 

The authors state that their schemes will work if records, 
or other units serve as the identifiable anit of object data, 
rather than files, which were mentioned throughout the paper. 
When records are allocated individually, there will be more mes- 
Sage traffic due to additional message requests for access to 
database objects. Nowhere in the paper is the problem of message 
congestion at the control node (when using the Centralized 
approach) discussed. With all requests for access to database 
objects being handled by the central DDBMF, there exists the 
possibility of a message bottleneck at the control node, which 
would degrade network performance due to slow response to the 
requests. 

It is mentioned that failure of the control node (when using 
the Centralized approach) can "paralyze the operation of the 
whole system," although all the DDBMF's can send all their in- 
formation to another DDBMF, thus recreating the global picture of 
the system at a newly designated control node. Although the 
author's Centralized approach may be "inefficient," it can be 
used to successfully detect all process deadlocks when only waits 


on database objects are involved. 


The Necentralized approach, as described in the paper, does 
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not detect all deadlock situations when only process waits for 


datahase objects are involved. Corsider the following example: 


Let the network consist of two nodes, A and B. Let 
processes P1 and P2, and files F1 and F2 be local to node A, 
and let processes P3 and P4, and files F3 and F4 be local to 
node B. Assume the following state of the network. (Figure 
III.1a contains a diagram for this "intermediate" state.) 

P1 has exclusive control of FY and is quéued waiting for 
access to F4, P2 is active (non«blo¢ked) and has exclusive 
control of F2, P3 has exclusive céntrol of FI and is queued 
waiting for access to F2, and P4¥ is #etive and has exclusive 
control of F&. P1 and P3 belong to class 2, as defined by 
Mahmoud and Riordon, and P2 and P& both belong to class 1 as 
long as each does not request access to a file located in a 
node other than the one in which the process resides. 

Now, within the same time interval, let P2 request ac- 
cess to F1 and let P4 request access to F3, thus creating a 
deadlock because neither file ean become available. (Figure 
III.1b contains the final state diagram for this deadlock.) 
P2 and P4 remain class 1 prodesses, and therefore these 
requests should be acted upon immediately and each node will 
check for deadlock using the information that it has. No 
deadlock will be detected because neither node has the in- 
formation about the recent request iff the other node, and no 


provisions are stated in the article which imply that 
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deadlock involving P2 or P4 will be checked for at the onset 


of the next synchronous clock period. 


The authors believe that class 1 processes do not contribute 
to deadlocks that involve processes waiting for files located in 
more than one node, and therefore deadlock can be checked for 
using only the information located at one node when a class 1 
process requests access to a file. It is this assumption that 
leads to the downfall of their Decentralized approach, because it 
is possible that a class 1 process will request access to a file 
controlled by a class 2 process, resulting in a deadlock (as 
shown in the previous example) involving processes which are 
collectively waiting for access to files located in two or more 
nodes. Note that this is similar to the flaw in the protocols 


for deadlock detection proposed by Chandra, Howe and Karp. 
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IV. Introduction to Proposed Solutions 

The deadlock detection schemes that are presented in 
Chapters V and VI are based on the creation and expansion of or- 
dered blocked process lists (OBPL's) and the restriction that a 
process may only have one unapproved outstanding resource request 
(and therefore be waiting for at most one resource at any 
instant). A resource may be any non-ambiguously defined portion 
of an object, whole object, or collection of objects which are 
requested as an entity and released as an entity by all users. 
(The case where there are several equivalent resources like tape 
drives is not considered. A discussion of physical devices oc- 
curs later in this chapter.) An OBPL is a list of process names, 
each of which (with the exception of the last process in the 
list) is waiting for access to a resource that has been assigned 
to the next process in the list. Each process name in the list 
is often referred to as a process entry in the OBPL, and when an 
OBPL is sent between nodes, a resource name is inserted into the 
single resource identification portion of the OBPL. The last 
process to have an entry in the OBPL is either waiting for access 
to the resource named in the resource identification portion, or 
it already has access to that resource. In the former case, it 
must be determined what process controls the resource, whereas in 
the latter case, the state of the last process in the OBPL must 
be determined. 

It is assumed that at each node there is a process manage~ 


ment module (PMM) which will handle deadlock detection and 
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resource allocation. It will maintain local state tables which 
will contain information about local resources (resources which 
are located in that node) and local processes (processes which 
are running in that node). If a PMM is checking for deadlock, 
and it is examining the OBPL with process entries P1, P2, ..., 
PN, then it knows that each process in the list (with the 
exception of PN) is waiting for the next process in the list to 
release a desired resource. If PN is not blocked, there is no 
deadlock and the OBPL can be discarded. If it is blocked, then a 
PMM must find out what process has been allocated the resource 
for which PN is waiting. If this process already has an entry in 
the OBPL, there is a deadlock, otherwise a PMM must append the 
process name to the OBPL and repeat the above. The schemes that 
are being proposed differ from each other in the way the OBPL's 


get expanded. 


IV.1 Descriptions of Resources 

There are three types of resources that a process may wait 
for where the blocking of the process can result in a deadlock. 
They are database objects, message text from other computerized 
processes, and message text from operators (manual processes). A 
distinction is made between message text from processes and mes- 
sage text from operators because a deadlock which involves no 
operator messages can be detected without operator interaction, 
whereas if a process is waiting for message text from an opera- 


tor, a deadlock can not be detected without the operator stating 
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what he/she is waiting for. The reason for the latter point is 
that an operator typically does not type in "receive message" 
statements, but accepts output as it is given. In the algorithms 
presented, it is assumed that an operator can only wait for a 
message from a process with which he/she is communicating (a 
discussion of operator and process communication is given later 
in this section). This restriction can be relaxed, and it is 
discussed in Chapter VIII. 

Database objects, as discussed in this paper, can be fields, 
records, files, or any other logical or physical component of a 
database. It is important that all processes treat the same 
portion of a database identically for the purposes of allocation. 
The level of granularity (which may vary for different database 
objects) at which database objects are allocated is unimportant 
for the detection of deadlock: it does however, affect the 
frequency of deadlock and, conversely, the burden of maintaining 
information about resource allocation. 

Message text must be treated differently from database ob- 
jects because once a message text has been assigned to a process, 
it is not available to any other process. In this sense, once a 
message text has been assigned, it no longer exists for future 
assignment. To ensure that a process receives the proper message 
text, the sending and receiving processes must create a unique 
connection over which message text between the two processes may 
pass. When a process would like to receive message text, it must 


state over which previously established connection the text 
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should come. Similarly, when a process wants to send message 
text, it must give the message text and name the connection over 
which the text should pass. All messages that are sent and 
received over a given connection will be referred to as text 
within a specific message group. 

When message text is sent by a process, it is queued for 
receipt at the proper destination end of the connection. A pro- 
cess may send several items of message text over a given connec- 
tion before any messages are requested by the other process as- 
sociated with the connection. In this case the items of message 
text are queued for receipt in a first in, first out manner. It 
is assumed that message management has infinite queueing 
capacity, and therefore the possibility of a deadlock involving a 
process which wants to send a message but is blocked because 
there is no place to put the message text will not be dealt with. 

Unlike process to process messages, which may be sent be- 
tween nodes, when a process and an operator communicate, they 
must be located at the same node. Similarly, however, an 
"operator connection" must be established between the operator 
and process before message text can be sent over the connection. 
The operator connection must be specified when message text is 
sent or received over the connection. When messages are sent 
from a process to an operator, they are usually printed immedi- 
ately at the operator's terminal. However, messages that are 
sent from an operator to a process are queued for receipt in the 


same manner as process to process messages. 
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All of the resources described above are uniquely identifi- 
able, and are allocated dynamically (i.e. during the execution of 
the process requesting access to the resource). None of them are 
physical devices (tape drives, printers, etc.), which are often 
not uniquely identifiable (there may be N of a kind). Physical 
devices are not considered by the algorithms that are being pro- 
posed because they are typically allocated to a process before 
execution begins and the known networks restrict processes to 
requesting physical devices at the same node. (If a process 
wants to control a physical device at another node, it must do so 
indirectly through a process located at the same node as the de- 
sired device.) Additionally, transaction oriented processes 


typically do not use dedicated devices. 


IV.2 Access to Resources and the Blocking of Processes 

A process may get blocked when it requests read only 
(shared) access or exclusive (read/write) access to a database 
object. While one process has exclusive access to a specific 
database object, all requests for access to that database object 
result in the requesting process being blocked. While at least 
one process has shared access to a specific database object, all 
requests for exclusive access to that database object result in 
the requesting process being blocked, and requests for shared 
access to that database object will result in the requesting 
process being blocked or being granted access to the desired 


resource (depending upon the resource allocation scheme in use). 
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Recause data values are not changed when a process only reads a 
database object, any number of processes may be allowed to have 
concurrent read only access to a database object. When all pro- 
cesses that had shared access to a given database object have 
released it, or when a process releases a database object from 
exclusive use, at least one process will be awakened and granted 
access to the newly released database object, if any were waiting 
for access to it. 

Once a process has been granted shared access to a specific 
database object, subsequent requests by that process for exclu- 
sive access to that database object are rejected. This restric- 
tion prevents a process from getting blocked waiting for a 
database object that it already has access to, and implies that a 
process must declare its most restrictive use when it requests 
access to the database object. (It must request exclusive access 
if there is any chance that the process might change the content 
of the database object.) In order to ensure that a process has a 
consistent view of the database, and that processes may be rolled 
back to a previous state (when necessary), no database objects 
will be released by a process until that process has reached a 
"commitment point", at which time all the database objects that 
the process had access to are released. A commitment point is 
always reached at process termination. (When a process continues 
processing after reaching a commitment point, for purposes of 
detecting deadlock, a PMM can treat it as a new process because 


it released all its database resources, and notified all pro- 
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cesses to which it could send messages that ne more messages are 
forthcoming. The external effects of a process, including | 
database updates and message text sent, can not be cancelled 
after commitment. ‘Process seuaitneat points ane synchronized, 
which is to say that after a process reaches a commitment point, 
it does no further processing until all npocesaes with which it 
has established connections over which it jan rackive messages 
have also reached commitment points.) . | 

If a process attempts to receive message text over a speci- 
fic connection, it will be given one message if any ste queued 
for receipt at that process'es end of the connection. If no 
messages are available, the process is blocked until message text 
arrives. Upon arrival of a message, the process will be 
awakened, because the receiving process is uniquely identified by 
the connection over which message text is sent. Steps must be 
taken to ensure that the receiving process and the sending pro- 
cess of a message treat the sane text. as one aeawnge: (one pro- 
cess can't treat a line as a message when the other process 


treats a group of sentences as a message. ) 


IV.3 Creation and Expansion of an OBPL 

When a PMM wants to check whether a given bloeked process is 
involved in a deadlock, it creates an OBPL-and inserts the net- 
work unique name of the process as the first process entry in the 
OBPL. (It is assumed that operators, processes and resources 


have unique names within a node, and these names can be made 
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unique within a network by qualifying them with the name of the 
node in which they reside. Throughout this Thesis, operator, 
process and resource names are assumed to be network unique.) 
Call this process P1. Let R1 be the resource to which P1 desires 
access. R1 is then inserted into the resource identification 
portion of the OBPL. A PMM (which PMM depends upon what scheme 
is being used to detect deadlock, and whether P1 and R1 are in 
the same node) then determines what process controls R1. If R1 
is a database object, then the process that controls R1 is the 
process that has access to it. (If there are several shared 
readers of R1, then it is said that each reader controls R1 and 
the ORPL is copied enough times so that there is one list for 
each reader of R1, and a different copy of the OBPL is used for 
each reader.) If R1 is message text in a message group, then the 
process that controls R1 is the process that can send the desired 
message, and if R1 is message text from an operator connection, 
the process that controls the resource is the human operator that 
can send the message. If R1 is message text over a connection to 
which no process other than P1 has associated itself, the PMM 
saves the OBPL so that after another process or operator associ- 
ates itself with the connection the needed information will be 
available and the OBPL can be expanded further. It is assumed 
that no deadlock can exist unless two processes are associated 
with the connection over which the desired message text can be 
received. 


Let PK be the process that controls R1. A PMM then checks 
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if PK already has an entry in the OBPL that is being examined. 
If it doesn't, the PMM adds its name to the ORPL and then lets 
some PMM determine if PK is active. If PK had an entry in the 
OBPL, the PMM has detected a deadlock, and should take the ap- 
propriate action. Note that the entry for PK ae - anywhere in 
the OBPL, as it is possible that a process not involved in the 
deadlock may be waiting to access a resource sontret ies by a 
process that is involved in the deadlock. If PK is active, then 
there is no deadlock and the OBPL can be discarded. TF PK is 
blocked, then the above procedure should be repeated, except PK 
should be used instead of P1 and a PMM determines what resource 
PK is waiting for. If PK represents an Sparator, then the PMM 
must save the OBPL until information about the status of the op- 
erator becomes available. A message is sent to the operator 
stating that this state information is desired. If the operator 
sends message text ‘6 a process, or if the operator responds that 
he/she is active, then all OBPL's that needed state information 
about this operator are discarded since there is currently no 
deadlock. If the operator states that he/she is waiting, then 
the operator connection over which the operator is awaiting a 
menceee must also be stated. The process that ean send the op- 
erator the denired mepeece is eerernieed ores the connection 
name, thus the PMM now knows what process controls the resource 
the operator desires, and this information is used to further 
expand all the OBPL's that needed state information about the 


operator. If no OBPL's needed this information, and the operator 
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volunteers the information that he/she is blocked, then an OBPL 
is created with the first process entry representing the opera- 
tor. 

In order to ensure. that a PMM sees a consistent set of state 
tables, no resources get allocated or released in the node of the 
PMM while the PMM is examining an OBPL. (The PMM holds exclusive 
use of the state tables in its node. The reason for this re- 
striction becomes apparent in Chapter VI in the verification of 
the decentralized algorithm.) There is no .chance of a PMM itself 
being involved in a deadlock because it is the only process that 
has access to the state tables in its node, and it does not wait 
for any messages or request access to any other database objects. 
Resource requests and OBPL's arriving from other nodes result in 
subroutine calls to the PMM. These calls are handled in a FIFO 
sequence. In addition, when a process or operator associates 
itself with a connection, a PMM is called to check if any OBPL's 
have been saved waiting for this information. Furthermore, when 
an operator sends message text to a process or states that he/she 
is active or blocked, the PMM at that node checks if any OBPL's 
have been saved waiting for state information about the operator 
and takes the appropriate action. 

The time at which an OBPL gets created depends upon the 
optimization of the deadlock detection scheme, and which PMM 
creates the ORPL depends upon what scheme 
(centralized/decentralized) is used. An OBPL can be created as 


soon as a process becomes hlocked, or it can get created after 
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'X' units of time have elapsed without the process gaining access 
to the desired resource. The latter approach will be used with 
the expectation that normally the process will be granted access 
to the desired resource within 'X' units of time because deadlock 
does not exist. Thus the overhead involved in creating and 
expanding an OBPL will usually be avoided. However, within the 
body of this paper, in the interest of clarity it is assumed that 
an OBPL is created immediately after it is determined that a de- 
sired resource is currently unavailable. It should be understood 
that the removal of this assumption, and the imposition of a 
delay before the OBPL gets created, does not impair the 
effectiveness of the algorithms because once a deadlock occurs, 
it exists until some type of recovery action is initiated. 
Certain information must be available to the PMM's if the 
OBPL's are to be properly expanded. The PMM at each node will 
maintain a table which has an entry for each process in its node. 
Associated with each process entry will be a list of all the 
resources to which the process currently has access, and the name 
of the resource to which the process desires access (if the pro- 
cess is waiting). For each resource at the node, the PMM must 
keep information stating what process or processes currently have 
access to that resource, and what type of access they have. In 
addition, a list of all processes that are waiting for access to 
that resource must be maintained. (The latter information is 
necessary so that the resources will be properly allocated when 


they become available.) 


37 


V. Centralized Approach to Deadlock Detection 

A "centralized" approach to deadlock detection in a computer 
network is based upon the premise that one node (the "control" 
node) in the network will act as the center of activity for glo- 
bal resource allocation and deadlock detection. In order to re- 
duce overhead, any requests for resources or checks for deadlock 
that can be handled entirely by one node should not request the 
service of the control node. For reasons that will be explained 
later, the following description has not been refined, and should 
not be viewed as a working algorithm. The description presents 
some ideas that could form the basis for a practical centralized 


approach to deadlock detection. 


V.1 Allocation of Resources 

A process management module (PMM) will have responsibility 
for granting access to a local resource as long-as no remote 
processes have been allocated the resource nor have been queued 
for it. When these conditions do not hold, the control process 
management module (CPMM) (located in the control node) will have 
responsibility for granting access to the resource. Thus when a 
process desires a remote resource, the request must go to the 
CPMM. When a process requests a local resource, the request must 
go through the CPMM only if that module currently has responsi- 
bility for granting access to the resource, otherwise the request 
will be handled by the local PMM. The set of resources for which 


the CPMM grants access changes dynamically. (As soon as a pro- 
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cess requests a remote resource, that resource becomes a member 


of the centrally managed set if it isn't already a member, and 


when the conditions above are satisfied again, the resource is 


removed from the set.) For each resource in the set, the CPMM 


maintains a list (in the global resource control table) of all 


processes queued for that resource plus the name of the process 


or processes (in the case of shared access) that have been al- 


located the resource. 


There are essentially three classes of resource requests in 


this type of network. The following is a list of the resource 


request classes and the proper response to each type of request: 


1. 


A process requests a resource at the same node as the 
process, and the local PMM is responsible for granting 
access rights to the resource: The PMM can block the 
process or give it the resource. In either case, the 
PMM can update the appropriate tables. 


A process requests a resource at the same node, and the 
CPMM has been given responsibility for granting access 
rights to the resource: A message containing the 
resource request must be sent from the local PMM to the 
CPMM. The local PMM will block the process until it 
receives notification from the CPMM that the desired 
access has been granted. Upon receipt of the resource 
request, the CPMM will either grant the process access 


_to the desired resource, or keep it blocked. In either 


case, the CPMM updates its tables to reflect the state 
after this request has been processed. 


A process requests a resource at another node: A mes- 
sage containing the resource request must be sent from 
the local PMM to the CPMM. The local PMM will block the 
process until it receives notification from the CPMM 
that the desired access has been granted. Upon receipt 
of the resource request, the CPMM, if it had the re- 
sponsibility for granting access to the specified 
resource, will either grant the process access to the 
desired resource or keep it blocked. If the CPMM did 
not have such responsibility, it will demand it from the 
PMM that does, and then the CPMM will process the 
request. After the request has been processed, the CPMM 
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will update its tables appropriately. 

When a process reaches a commitment point, the local PMM 
will release all the resources that the process controlled. The 
PMM can then grant other local processes access to the resources 
that were released and for which it has responsibility for 
granting access. If any resources which were under the CPMM's 
control were released, the CPMM will be notified of the reaching 
of a commitment point by the process, and it will then grant 
other processes access to the resources if any are queued for 
them and the rules for resource allocation permit the new 
assignments. If possible, following a resource release, the CPMM 
will return responsibility for granting access to a resource back 


to the PMM in the node where the resource resides. 


V.2 Deadlock Detection 

When a PMM denies a request for a resource and blocks a 
process, it then creates an OBPL with a process entry for the 
blocked process. It then expands the OBPL until 1) a deadlock is 
detected, 2) it is ascertained that there is no deadlock, or 3) 
the PMM does not have enough information to expand the OBPL fur- 
ther (because an involved process is waiting for a global 
resource, or a local resource is controlled by a remote process). 
In the latter case the PMM sends the OBPL to the CPMM, which will 
complete the expansion of the OBPL. When the CPMM denies a 
request for access to a resource, it creates an OBPL with a pro- 


cess entry for the blocked process and then expands the OBPL un- 
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til a deadlock is detected or it is ascertained that no deadlock 
exists. 

To expand an OBPL, a PMM uses its state tables that were 
described in Chapter IV, and the CPMM uses its global resource 
tables and those of the PMM's in the network. (How it obtains 
copies of these tables is discussed later in this chapter.) The 
method by which ihe PMM's expand an OBPL will be described first, 
and it will be followed by the method which is used by the CPMM. 
After a PMM has created an OBPL, it acts as if it were in step 2 
below, with PN set to the name of the process which was just 
blocked, and RN set to the name of the resource for which PN is 
waiting. The following is a list of steps taken by a PMM when 
expanding an OBPL: 


1. Let PN be waiting for resource RN. If RN is a local 
resource, go to step 2, otherwise go to step 6. 


2. If RN is controlled only by local processes, go to step 
3, otherwise go to step 6. 


3. Let PX be the process controlling RN. If PX is blocked, 
go to step 4, otherwise there is no deadlock and the 
OBPL can be discarded. (If there are J shared readers 
of RN, repeat this step once for each reader.) 


4, If PX is already contained as a process entry in the 
OBPL, there is a deadlock and the PMM must take appro- 
priate action. If PX is not in the OBPL then go to step 
5 


5. Append PX as a process entry in the OBPL and go to step 
1, where PX is used in place of PN. 


6. Place RN into the resource identification portion of the 
OBPL and send the OBPL to the CPMM. Halt. 


The CPMM will create an OBPL when it denies a request for 


access to a resource. The only process entry in the newly cre- 
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ated ORPL is for the process whose resource request could not 
currently be honored. After a CPMM has created an OBPL, it 
starts in step 1 below, with RN set to the resource whose 
unavailability resulted in the OBPL being created. If the CPMM 
receives an OBPL from a PMM, it sets RN to the resource that was 
placed in the resource location of the OBPL, and sets PN to the 
last process to be inserted into the OBPL. The CPMM verifies 
that PN is still waiting for RN (if it isn't, either RN has al- 
ready been allocated to PN or the CPMM has not yet received the 
request by PN for access to RN, so there is currently no deadlock 
and the OBPL can be discarded) and then starts in step 1 below. 
The following is a list of steps taken by the CPMM when expanding 
an OBPL: 

1. Let PX be the process controlling RN. (If there are J 
shared readers of RN then repeat this step once for each 
reader.) ‘To find PX, the CPMM first checks if RN is in 
the global resource table. If it is, then this table is 
used to get PX, otherwise the copies of the local tables 


for the node in which RN resides are used by the CPMM. 
Go to step 2. 


2. If PX is blocked, go to step 3, otherwise there is no 
deadlock and the OBPL can be discarded. (First check if 
PX is waiting for a global resource, and if it isn't, 
then check the copies of the local tables for the node 
in which PX resides in order to find out if PX is 
blocked or active.) 


3. If PX ts already contained as a process entry in the 
OBPL there is a deadlock and the CPMM must take appro- 
priate action. If PX is not contained in the OBPL, go 
to step 4. 


4, Append PX as a process entry in the OBPL and go to step 
5, where PX is used in place of PN. 

5. Let PN be waiting for RN. (If PN is waiting for a glo- 
bal resource, use the global resource table to determine 
RN, otherwise use the copy of the local tables for the 
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node in which PN resides.) Go to step 1. 


V.3 Issues to be Resolved 

There are several problems with the algorithm as described 
in the previous section. A major problem is determining how the 
CPMM maintains its copies of the tables belonging to the PMM's in 
the network. One possibility is to have each PMM send a copy of 
its tables to the CPMM every 'X' units of time. Another is to 
have the CPMM request a new copy of the tables that it needs if 
'y' units of time (Y may equal 0) have elapsed since it last 
received a copy of the desired table. In either case, once a 
deadlock has been detected, all the tables of the nodes whose 
processes and resources are involved should again be requested by 
the CPMM in order to verify that the deadioek exists and that the 
CPMM's detection was not a result of the CPMM looking at an 
inconsistent state of the network. (Due to the fact that the 
list of resources that are kept in the global resource table 
changes dynamically, and the CPMM does not always have an up to 
date copy of the local tables, it is possible that some needed 
information may be incorrect and could cause problems for the 
CPMM.) It is probable that there are better and more reliable 
methods of maintaining the copies of the local tables in the 
CPMM, 

When the CPMM is expanding an OBPL, and encounters a process 
waiting for message text from an operator, it can be difficult to 


get the needed state information. A method is needed whereby the 
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CPMM can save the OBPL and notify the PMM at the node in which 
the operator resides, that this state information is desired. 
The PMM must then query the operator and send the CPMM this in- 
formation along with its latest state tables. 

Another problem that must be resolved occurs when related 
messages cross between two nodes. An example of this is that the 
CPMM may return the rights to grant access to a resource to a PMM 
at the same time that the PMM under discussion sends a request to 
the CPMM stating that one of its processes would like to access 
that local resource. Care must be taken when designing the 
resource allocation scheme to ensure that cases like this will be 
detected and the desired action (which in this case is granting 
the process access to the resource) will occur. In addition, 
steps must be taken in the deadlock detection algorithm to ac- 


count for and detect similar problems. 


V.4 Reasons for not Refining the Algorithm 

Several factors led to the decision not to refine the above 
algorithm to the point where it could easily be proved to work. 
It was felt that with all remote resource requests going to one 
node, there would be message congestion at that node, plus there 
would be an extra delay due to the fact that a request must go 
through the central node rather than going directly to the node 
in which the desired resource resides. Another factor that in- 
fluences message congestion is the size of the tables that will 


get sent from the PMM's to the CPMM. Since database records may 
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be considered resources, these tables can get quite large, and it 
would be preferable to only send the CPMM parts of these tables, 
but then there is the problem of deciding which parts should be 
sent, and what the CPMM should do when it was not sent enough 
information. 

When one node is used as the center of activity in a net- 
work, the network becomes only as reliable as that node. It 
would be possible to have another node in the network serve as a 
backup to the CPMM and maintain copies of the CPMM'S tables. 
There would be a delay in updating this duplicate copy, and it 
would have to be decided how often the copy should be updated. 

(A great deal of overhead is involved if a message is sent to the 
"backup" node every time the CPMM changed its tables.) It would 
also be possible to reconstruct the CPMM's tables at another node 
by requesting information from all other nodes in the network, 
thus saving the overhead involved in maintaining the duplicate 
copy at a cost of added delay if the control node were to become 
inoperable for some reason. In a computer network it is desira- 
ble to distribute the computing and to minimize the overall net- 
work problems when one node crashes. This was the major reason 
it was decided not to spend time refining an algorithm for 


deadlock detection which relies upon one node in the network. 
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VI. Decentralized Approach to Deadlock Detection 
A “decentralized" approach to deadlock detection in a com- 
puter network is hased upon the premise that there should be no 
central or control node and that all nodes in the network will 
share the responsibility for detecting deadlocks. In addition, 
the failure of one node should only affect the processes of that 
node and the processes of other nodes which are accessing that 
node's resources. The amount of duplicate process and resource 
state information among the various nodes in the network will be 
kept to a minimum, and each node will be requested to help check 
for a deadlock only when at least one of its processes or 


resources is involved. 


VI.1 Allocation of Resources 

A process management module (PMM) located at each node will 
always have responsibility for granting access to resources lo- 
cated at that node. Whenever a process requests a resource, the 
request will be processed by the PMM at the same node as the 
process. This PMM will determine if the desired resource is lo- 
cal or if it is located at a different node. (Message text 
should be treated as local to the node of the sending process.) 
If it is a local resource, then the PMM can immediately determine 
if the desired access may be granted or if the process must be 
blocked waiting for the availability of the resource. If the 
request is for a remote database object, then the PMM must block 


the process and send a remote database object request (RDOR) to 
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the PMM in the node which contains the desired resource. Upon 
receipt of an RDOR from another node, a PMM will determine if the 
requesting process must remain blocked or if it may be granted 
access to the desired resource. If access is granted, a remote 
database object assignment (RDOA) is sent to the PMM in the node 
in which the requesting process resides. Upon receipt of this 
RDOA, the PMM will awaken the proper process and notify it of the 
resource assignment. If the process must remain blocked, no 
message is sent to the node in which the process resides. The 
details of implementing this feature are not described, as they 
are not relevant to the scope of this Thesis. 

When a process reaches a commitment point, the PMM at its 
node will release all the database resources that the process had 
access to and notify the necessary processes that no more mes- 
sages are forthcoming from the specified process. All local 
resources can be immediately allocated to other processes in ac- 
cordance with the rules for resource allocation, and messages 
must be sent to all nodes which had resources allocated to the 
process, informing their PMM's of the reaching of a commitment 
point. Upon receipt of such a message, the PMM will 
appropriately update its tables and assign the resources to other 


processes in accordance with the rules for resource allocation. 


WVI.2 Deadlock Detection 
When a PMM determines that a resource at its node can not - 


currently be allocated to a process that requested it, the PMM 
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creates an ORPL (ordered blocked process list) with a process 
entry for the blocked process. It then expands the OBPL until 1) 
a deadlock is detected, 2) it is ascertained that there is no 
deadlock, or 3) the PMM does not have enough information to fur- 
ther expand the OBPL. (Note that if a database object has been 
requested, the ORPL is created in the node where the database 
object resides, whereas if message text has been requested, the 
OBPL is created in the node where the requesting process 
resides.) The PMM starts expanding the newly created OBPL in 
step 10 below. When a PMM receives an OBPL from another node, it 
starts in step 1 below in an attempt to complete the expansion of 
the OBPL. The reasoning behind each step is contained in the 
next section, and these explanations should be read before one 
attempts to verify the correctness of the algorithm. It should 
be noted that within the algorithm, PX and RX are names of vari- 
ables whose contents represent processes and resources, respec- 
tively, even though they are sometimes used as though they were 
process and resource names themselves. 

1. Set RX to the value contained in the resource 
identification portion of the OBPL. If RX represents a 
resource which is local to the node expanding the OBPL, 
then go to step 2, otherwise go to step 8. 

2. Verify that the last process added to the OBPL is still 
waiting for RX. If it isn't then discard the OBPL and 
halt, otherwise go to step 3. 

3. Let PX be the process controlling RX. (If there are J 
shared readers of RX, then repeat this step once for 
each reader.) If PX already has a process entry in the 
OBPL, then there is a deadlock and the PMM must take the 


appropriate action. If PX is not in the OBPL then go to 
step 4. 
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10. 


11. 


If PX represents a process which is local to the node 
expanding the OBPL, then go to step 5, otherwise go to 
step 7. 


If PX is active, there is no deadlock, so discard the 
OBPL and halt. Otherwise go to step 6. 


Append PX as a process entry in the OBPL and go to step 
10. 


Append PX as a process entry in the OBPL. Place RX into 
the resource identification portion of the OBPL and send 
the OBPL to the PMM in the node in which PX resides. 
Halt. 


Verify that the last process added to the OBPL still has 
access to RX. If it doesn't, discard the OBPL and halt. 
Otherwise go to step 9. 


If the last process added to the OBPL is active, there 
is no deadlock, so discard the OBPL and halt. Otherwise 
go to step 10. 


Get the name of the resource for which the last process 
added to the OBPL is waiting and call it RX. If RX 
represents a resource which is local to the node 
expanding the OBPL, go to step 3, otherwise go to step 
11. 


Place RX into the resource identification portion of the 
OBPL and send the OBPL to the PMM in the node in which 
RX resides. Halt. 


VI.3 Explanation of Steps in the Deadlock Detection Algorithm 


The following is a description of the reasons for including 


each step in the deadlock detection algorithm described in the 


previous section. Each numbered paragraph below corresponds to 


the step with the same number in the previous section. 


1. 


An OBPL will be sent to a node when it must be deter- 
mined what process controls a given resource, or what 
state (active or blocked) a given process is in. If the 
resource that was named in the resource identification 
portion of the OBPL is local to the node that just 
received the OBPL, then in order to expand the OBPL the 
PMM needs to know what process has access to that 
resource and it goes to step 2, otherwise it goes to 


49 


step 8 in order to check the state of the last process 
to be added to the OBPL. 


It must be verified that the last process added to the 
OBPL is still waiting for RX because it is possible that 
while the OBPL was sent from the PMM in the node con- 
taining the process, the PMM in the node containing RX 
sent a message stating that the process has been granted 
access to RX. If this process is no longer waiting for 
RX, the state that was assumed when the OBPL was sent no 
longer exists, and the OBPL can be discarded. 


If RX represents a database object, then the last pro- 
cess added to the OBPL is still waiting for RX if it is 
still queved for access to the database object. If RX 
represents a message in a message group, then RX is 
qualified by the sequence number of the message within 
the message group that is desired. (If the process has 
already received N messages over the specified connec- 
tion, then it is waiting for message number N+1 in the 
message group.) The process is still waiting for the 
specified message only if the number of messages already 
sent to it over the given connection is less than the 
number that qualified the message group name. 


If PX already has a process entry in the OBPL, then 
there is a loop of processes each waiting for a resource 
that is controlled by the next process in the loop, so a 
deadlock has been detected. If PX does not have a pro- 
cess entry in the OBPL, go to step 4 in order to expand 
the OBPL further if PX is not active. 


If RX is a database object which has J shared readers, 
then a copy of the OBPL must be made for each of these 
readers because the process that requested access to RX 
will not be able to access RX if the process is ina 
deadly embrace loop involving any one of the J readers. 


If PX is local to the node which is expanding the OBPL, 
then the PMM can immediately check the state of PX, so 
it goes to step 5. If PX is not a local process, the 
OBPL must be sent to the node in which PX resides, so 
the PMM goes to step 7. 


If PX is not currently blocked waiting for access to any 
resources, there can be no deadlock currently involving 
PX. If PX represents an operator, the OBPL must be 
queued waiting for state information about the operator. 
The PMM will then ask the operator to enter information 
about his/her state. The acceptable operator responses 
are 1) that he/she is waiting for a message over a given 
operator connection, 2) that he/she is active, or 3) a 
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10. 
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regular message over an operator connection. If the 
operator sends a regular message, or states that he/she 
is active, then there is no deadlock and all the OBPL's 
that are queued for state information about this opera- 
tor will be discarded. If the operator ‘states that 
he/she is waiting for a message, ‘then the PMM can (by 
the use of the given operator connection) determine what 
process can send the message thet tte operator desires, 
and the PMM can then further expand the OBPL. It may be 
desirable to "time out" a non-responsive operator, as 
operator inaction can stall the system and perpetuate an 
undetected deadlock... - 


PX is blocked, so insert it as the last entry in the 
OBPL and then go to step ‘10 in order to further expand 
the OBPL. 


Insert PX as the last entry in the OBPL even though the 
PMM does. not know the state: (active or blocked) of PX. 
(This will be checked by the node that will receive the 
OBPL.) Place RX into the resource tdenttification 
portion of the OBPL to indicate that PX currently con- 
trols. RX, and the state of PX is needed information. If 
RX represents a message within a message group, it is 
qualified by the sequence: number. of ‘the message within 
the message group that is desired. The PMM therefore 
sends the OBPL for further expansion to the PMM in the 
node which contains PX. 


It must be verified that the last process added to the 
OBPL still has access to RX because it is possible that 
while the OBPL was sent from the PM in the node con- 

taining RX, the PMM in the node containing the process 


‘sent a message stating: that RX has been released by the 


process. If the process no longer has access to RX then 
the state that was assumed: when the: OBPL’was sent no 
longer exists, and the OBPL can be discarded. 


If the last process added to the OBPL is not currently 
blocked waiting for access: to any reséurces, there can 
be no deadlock currently involving the process. If the 
process is blocked, the PMH: goes to step TO“ because the 
process already has been inserted as the last process 
entry in the OBPL. 


Step 10 can be reached from step 6 or step 9. In either 
case, the last process added to the OBPL is local to the 
node which. fs expanding the OBPL, so the PMM ‘can find 
out what resource the process desires access to. Set RX 
to the name of this resource. If RX is Iocal to the 
node that is currently expanding the OBPL, the PMM can 
continue to expand the OBPL, so it goes to step 3, 
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otherwise it goes to step 11. 
11. To further expand the OBPL, what process has access to 
RX must be known, so the PMM sends the OBPL to the PMM 
in the node in which RX resides. Place RX into the 
resource identification portion of the OBPL to indicate 
that the last process added to the OBPL is blocked 
waiting for access to RX and what process controls RX is 
needed information. In the case where RX represents a 
message within a message group, it is qualified by the 
sequence number of the message within the message group 
that is desired. Send the OBPL for further expansion to 
the node in which RX resides. 
VI.4 Verification of the Algorithm 
There are two parts in the verification of the correctness 
of the decentralized algorithm for deadlock detection. The first 
and most important part is to prove that all deadlocks get 
detected. The second part is proving that a deadlock is not 
"detected" when (except in a special case discussed later) one 


does not exist. 


Part 1 

To prove that all deadlocks get detected, it will be 
shown that once a deadlock state is reached, an OBPL will be 
created that will be passed among nodes which will expand it 
until the deadlock is detected. There are two assumptions 
that are required for this proof: 1) All internodal mes- 
sages eventually get received by the proper nodes (and 
therefore no OBPL's are "ost" in the transmission between 
nodes), and 2) while the OBPL is being expanded, none of the 
processes involved in the deadlock are aborted (which would 


break the deadlock before it is detected) or rolled back to 
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a previous state (which would imply the deadlock has been 
detected by the expansion of another OBPL). 

Let a deadlock consist of processes P1, P2, ..., PN, 
with P1 waiting for a resource controlled by P2, ..., and PN 
waiting for a resource controlled by P1. (Process names are 
unique within a node and they can be made network unique by 
qualifying them with their node names, so throughout this 
proof, assume the Pi represent distinct processes.) When 
each process, Pi, involved in the deadlock was denied access 
to a resource controlled by another process in the deadlock, 
an OBPL was created with the first process entry represent- 
ing Pi. One of these OBPL's must have been the last (in 
time) to be created, thus the deadlock existed at that time. 
(If two or more of these OBPL's were created simultaneously 
and they were the last to be Svidated for processes involved 
in the deadlock, then any one in this "last group" may be 
arbitrarily selected as the last to be created. The 
important point is that the deadlock existed at the time the 
OBPL was created, and all the relevant tables collectively 
contain the information showing each process in the deadlock 
waiting for a resource controlled by another process in the 
deadlock.) For simplicity, assume that this last OBPL con- 
tains P1 as its first process entry. Additionally, in the 
ensuing discussion, a message from an operator to a 
computerized process will not be treated as a special type 


of resource because it is assumed that operators will state 


aS 


what they are waiting for when asked to do so by a PMM. 
After P1 has been inserted as the first process entry 
in this "last" ORPL, the PMM which will begin the expansion 
of the ORPL will be in step 10 of the algorithm. If P1 is 
waiting for access to a resource local to a different node, 
then the PMM executes steps 10 and 11, and another PMM 
(after receipt of the OBPL) executes steps 1 and 2, then 
goes to step 3, otherwise the PMM executes step 10 and goes 
to step 3. (Since there is a deadlock, the OBPL will not be 
discarded.) Now, no matter what P1 is waiting for, it can 
be assumed that a PMM is about to start step 3 and it can 
(i.e. it has the information in its tables) determine what 
process (in this case, P2) controls the resource P1 has re- 
quested. There are two ways (depending on whether P2 is 
local or global to the node in which the OBPL is currently 
located) in which a process entry for P2 will be inserted 
into the ORPL. 
Case A: P2 is “local". 
Steps 4, 5 and 6 are executed, then step 10 will be 
executed. The PMM will then be ready to execute step 3 
or it will execute step 11 and another PMM will execute 
steps 1 and 2, and will be prepared to execute step 3. 
Case B: P2 is "global". 
Steps 4 and 7 are executed, then the PMM which then 
receives the OBPL will execute steps 1, 8, 9 and 10. 
It will then be ready to execute step 3 or it will ex- 
ecute step 11 and another PMM will execute steps 1 and 
2, and will be prepared to execute step 3. 


This "last" OBPL now has process entries for P1 and Pe, 


and a PMM is about to execute step 3 to continue the 
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Part 


expansion of the OBPL. A PMM is now essentially in the same 
position some PMM was in shortly after the OBPL was created. 
The only difference is that now two processes have entries 
in the OBPL, and RX is set to the resource for which P2 is 
waiting, rather than the resource for which P1 is waiting. 
By repeating the above procedure as many times as necessary, 
the OBPL will be expanded to include process entries for 
processes P1, P2, ..., PN. At this point, when step 3 is 
executed, it will be determined that P1 controls the 
resource PN has requested, and the deadlock will be 
detected. 


QED Part 1. 


To prove that every deadlock that gets "detected" ac- 
tually is a deadlock, it must be shown that an OBPL will be 
discarded whenever there is a change in the state that was 
assumed when a process entry was made in that OBPL. (The 
one exception, which is ignored in the ensuing discussion, 
is the case where the assumed state changes due to the 
aborting or rolling back of a process, rather than having 
the state change due to a waiting process being awakened and 
granted access to the resource for which it was waiting.) 
This condition is sufficient because if a deadlock is 
"detected" when expanding the OBPL containing (in order of 


insertion) process entries for P1, P2, ..., PM, PN, and 
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there has been no change in the state that was assumed when 
each process was entered into the OBPL, then P1 is still 
waiting to access a resource controlled by P2, ..., PM is 
still waiting to access a resource controlled by PN, and PN 
is still waiting to access a resource controlled by PJ, 
where PJ appears earlier in the OBPL. Thus a deadlock ac- 
tually exists if one is "detected" and there has been no 
change in the state that was assumed when the process en- 
tries were inserted into the OBPL. 

Assume that a PMM is expanding an OBPL with process 
entries (in order of insertion) P1, P2, ..., PK, PL. If the 
algorithm is correct, then P1 is waiting for access to a 
resource controlled by P2, ..., and PK waiting for access to 
a resource controlled by PL. Now assume that this state 
does not hold. That is to say, for some Pi, Pj with adjac- 
ent process entries in the OBPL, either Pi is not waiting 
for access to the same resource (say RQ) for which it was 
waiting when it was ascertained that Pi was blocked and that 
Pi should have an entry in the OBPL, or Pj no longer con- 
trols RQ. It will be shown that whenever this situation 
occurs, it will be detected and the OBPL will be discarded. 

It can be assumed that Pi and Pj are PK and PL respec- 
tively, because if the state has changed from what was as- 
sumed when Pi was inserted into the OBPL, then it either 
changed before a PMM checked to see what Pj was waiting for, 


Pj was not blocked, or the state changed after there was a 
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similar state change involving Pj and the next process in 


the list. (The latter claim can be made because if Pi was 


waiting for access to RQ which was controlled by Pj, and Pj 


controlled RQ and was blocked at the time that it was 


decided to further expand the OBPL, the only way the assumed 


state could change would be for Pj to incur a state change 


and be awakened so that it could release RQ.) 


that 
that 
must 
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In order to show that PK is still waiting for RQ, and 
RO is still controlled by PL whenever it is decided 
another process should be added to the OBPL, two cases 
be considered. 1) PL, PK and RQ are all located in the 


node, and 2) PL, PK and RQ are located in two or three 


different nodes in the network. 


Case 1. 


Due to the restriction that operators can only 
communicate with processes, there are three possible 
combinations of the types (process or operator) of PL 
and PK. (The resource type of RQ is either unimportant 
or uniquely determined by PK and PL.) 


Case A: PK and PL are both processes. 
Once PK has been inserted into the OBPL, and the 
PMM in the node in which PK resides is expanding 
the OBPL, the PMM determines that PK is waiting 
for access to RQ and that PL controls RQ. It then 
inserts PL into the OBPL if PL is blocked and 
discards the OBPL if PL is active. Since the PMM 
has exclusive use of the state tables in its node, 
there is no way the assumed state will change un- 
til after the OBPL is discarded, sent to another 
node or queved waiting for state information about 
an operator (in which case the state can not 
change until after the operator states that he/she 
is active or sends a message to a process, both of 
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which result in the OBPL being discarded). 


Case B: PK is an operator and PL is a process. 
PK is not inserted into the OBPL until the opera- 
tor states that he/she is waiting for a message 
over a given operator connection (RQ). The PMM in 
the node in which PK resides then determines that 
PL is the process that can send the desired mes- 
sage. If PL is blocked, it is inserted into the 
OBPL, otherwise the OBPL is discarded. Since the 
PMM has exclusive control of the state tables in 
its node, the assumed state can not change until 
after the OBPL is discarded, sent to another node, 
or queued waiting for state information about an 
operator. 


Case C: PK is a process and PL is an operator. 
PL is not inserted into the OBPL until the opera- 
tor states that he/she is waiting for a message 
over a given operator connection. PK is still 
waiting for a message from PL because the OBPL 
would have been discarded if any message text had 
been received from the operator since the OBPL was 
queued waiting for state information about the 
operator. (Note that it is possible that the de- 
Sired message may have been sent by the operator 
before the OBPL was queued, but it has not been 
given to PK because calls to the PMM are processed 
in a first in, first out fashion. In this case 
though, the OBPL will be discarded before any 
State message from the operator is processed, be- 
cause the desired message text was sent before the 
operator state message.) The OBPL will then ei- 
ther be discarded or have another process entry 
added to it, because an operator can only wait for 
a message from a process located at the same node. 


Case 2. 
Whenever an OBPL is sent between nodes, it must be 
verified that the state that was assumed when the OBPL 
was sent is still valid. Operators do not cause any 
OBPL's to be sent between nodes (because they only 
communicate with processes at their own nodes), thus in 


this discussion PK and PL are always processes. There 
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are four combinations of the resource type of RO and 
the locations of PK, PL and RQ. 


Case A: RQ is a database object located in the same 
node as PK, but different from PL. 
After it is ascertained that PK is blocked waiting 
for access to RQ, it is determined that PL con- 
trols RQ. PL is then inserted into the OBPL 
(after the entry for PK) and the OBPL is sent to 
the PMM in the node in which PL resides. When the 
PMM receives the OBPL, it first verifies that PL 
still controls RQ. If it doesn't, there has been 
a change in the assumed state (PL has released 
RQ), and the OBPL is discarded. Note that the 
OBPL is also discarded if it is determined that PL 
is not blocked. 


Case B: RQ is a database object located in the same 
node as PL, but different from PK. 
After it is ascertained that PK is blocked waiting 
for access to RQ, the OBPL is sent to the PMM in 
the node in which RQ and PL reside. Upon receipt 
of the OBPL, this PMM verifies that PK is still 
waiting for access to RO. If it isn't, there has 
been a state change (PK was granted access to RQ), 
and the OBPL is discarded. The OBPL is also 
discarded if it is determined that PL (which con- 
trols RQ) is not blocked. 


Case C: RQ is a database object located in a node 
which contains neither PK nor PL. 
After it is ascertained that PK is blocked waiting 
for access to RQ, the OBPL is sent to the PMM in 
the node in which RQ resides. Upon receipt of the 
OBPL, this PMM verifies that PK is still waiting 
for access to RQ. If it isn't, there has been a 
state change, and the OBPL is discarded. If PK is 
still waiting for access to RQ, then the PMM in- 
serts PL into the OBPL (since PL controls RQ) and 
sends the OBPL to the PMM in the node in which PL 
resides. After the OBPL is received, the PMM then 
checks that PL still controls RQ. If it doesn't, 
there has been a change in the assumed state, and 
the OBPL is discarded. The OBPL is also discarded 
if it is determined that PL is not blocked. 


Case D: RQ represents message text and PK and PL are 
located in different nodes. 
After PK is inserted into the OBPL because the 
process is waiting for message text in message 
group RQ, RQ is qualified by a message number. 
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The ORPL is then sent to the node in which PL 
resides. PL will only be inserted into the OBPL 
if it is blocked and the specified message has not 
been sent (which implies PK is still in the state 
it was in when it was inserted into the ORPL), 
otherwise the OBPL will be discarded. 

It has been shown that whenever the relevant portions 
of the overall network state differ from the state that was 
assumed when process entries were inserted into the OBPL, 
the situation is detected and the OBPL is discarded. 
Therefore it is impossible to detect anything but deadlocks 
since a deadlock is never "detected" unless a PMM wants to 
insert a process into an OBPL when there is already a pro- 
cess entry in the OBPL for that process. It has thus been 
proven that the decentralized algorithm only "detects" 
deadlocks. 


QED Part 2. 


OED Decentralized Algorithm. 


VI.5 Some Properties of the Algorithm 

It should be noted that all references to processes in the 
previous sections actually referred to process "commitment units" 
(the period between commitment points), and the fact that 
commitment units within a process are network unique allows a 
deadlock to be detected at a node different from the one which 
contains the process that was found to already have a process 
entry in an OBPL. This situation can arise if the process under 
discussion controls a remote database object, and the PMM at the 


node in which the database object resides wants to insert the 


60 


process into the OBPL due to its controlling the above mentioned 
database object. The OBPL need not be sent to the PMM in the 
node in which the process resides to verify that the process 
still controls the database object, because the process has not 
reached a commitment point (by virtue of the fact it already has 
an entry in the OBPL) and therefore has not released any database 
objects. 

All resource requests will be handled with minimal delay 
because, for any request, the only nodes involved are those which 
contain the associated process and resource. (No information is 
needed from any other nodes to process the request.) The algo- 
rithm will function properly regardless of the resource 
allocation scheme in use, since the needed information about a 
resource is what process (or processes) currently controls it, 
not the order in which processes will be granted access to the 
resource in the future. (The latter information is necessary 
only for deadlock avoidance algorithms.) 

While a PMM is expanding an OBPL, all other PMM's may be 
processing resource requests and releases. A PMM need only see a 
consistent state within its own node in order to expand an OBPL. 
The restriction that a PMM can not process resource requests and 
releases while it is expanding an OBPL can be removed if the 
decentralized algorithm is modified slightly. In step 10 the 
branch to step 3 would be eliminated (and therefore always go to 
step 11 after step 10), and then in step 11 a PMM may send an 


OBPL to itself. The new restriction would be that no resource 
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requests or releases can be processed while a PMM is executing 
steps 1 through 11, although resource requests and releases could 
he processed between the execution of step 11 and step 1. 

The same deadlock can be detected more than once if pro- 
cesses and resources located in two or more nodes are involved. 
This situation will occur if two or more processes request 
request resources at approximately the same time, resulting in 
OBPL's being created starting with different processes in the 
same deadlock loop. It is important to note that no matter how 
long it takes for OBPL's, remote resource requests, remote 
resource assignments, message text in message groups, and noti- 
fication of a remote process termination to travel between nodes, 
the algorithm still functions as expected due to the verification 
steps that are included and the fact that once a deadlock exists, 
it will not be broken until after it is detected and recovery 


action is initiated. 
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VII. ADT Model of the Decentralized Algorithm 

A functional model of the decentralized algorithm described 
in the previous chapter was designed and created using the 
facilities of the Architectural Definition Technique (ADT). The 
model was designed so that the algorithm could be easily tested. 

Additionally, by designing the model at the same time that the 
algorithm was being refined, several deficiencies of early ver- 
sions of the algorithm were detected and corrected. (See section 
VII.2 and [1] for information about ADT.) 

The model was written in PL/I and runs on the Honeywell 
Multics timesharing system. It was coded for ease of use and 
readability, and is not intended to suggest the most efficient 
way of implementing the algorithm in a computer network. A pre- 
requisite to the use of ADT is an ability to understand the con- 


cept behind Data Structure Diagrams. 


VIIT.1 Data Structure Diagrams 

An information structure can be described by a Data Struc- 
ture Diagram. A particular object in an information structure is 
referred to as an "entity", and an entire group of similar enti- 
ties is called an “entity-class". (They are characterized by a 
prototype called an "entity-type".) The grouping that associates 
one or more entities of the same entity-class with one entity of 
a second entity-class (same or different type) in a subordinate 
relationship is known as an "entity-set". In a Data Structure 


Diagram, a block is used to represent an entity-type (the 
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entity-type name is written inside the block). A "“set-class" is 
a collection of similar entity-sets. (They are characterized by 
a prototype called a "set-type".) An arrow represents a 
set-type. It designates (by pointing from) the entity-type that 
"owns" the set-type and designates (by pointing to) the 
entity-type that serves as the "members" of the set. 

There is a 1 ton relationship between the owner and members 
of an entity+set: n may be zero, one or more. For each owner 
there may be any number of members, Sut for each member, there is 
only one owner in afy set occurrence. A dashed arrow is used to 
represent a set-type where the member relationship may és may not 
exist. This is called a "sometime" member relationship. When 
there can be only one member in an entity-set, a line (rather 
than arrow) is drawn between the owner entity~class and member 
entity-class. A dashed line is used when there can be a sometime 
one-to-one relationship. 

A situation ean arise where a set-type can have more than 
one type of entity in the member role. In this case a multihead 
arrow is used to represent the set=-type. Similarly, a multitail 
arrow is used to represent a set+-type where more than one type of 
entity can assume the owner role (although eath member has only 
one owner). <A more detailed explanation of Data Structure 


Diagrams can be found in [2]. 


VII.A Architectural Definition Technique 


ADT is an approach to arriving at a complete, concise, 
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non-ambiguous functional specification of a software or hardware 
system which is totally independent of packaging considerations. 
To use ANT, one must describe the system state variables in terms 
of occurrences of entity-types, attribute types and set-types, 
and create a user interface as a set of machine processable 
function definition algorithms. 

An example of an entity-type is "node" in a computer net- 
work. Each node in the network must have a name, which is an 
attribute of the entity. The entity-type and its attributes must 
be declared. In addition, all entity-sets which a node may 
belong to as a member or owner must be declared, and the rela- 
tionship ("member", "owner", or "recursive") must be stated. A 
node is a member of the set of all nodes in a network, but it is 
the owner of various resources and processes located at that 
node. The manner in which entities and their attributes and set 
relationships are represented in the machine is irrelevant to the 
goal of achieving a functional specification. Therefore the ADT 
user is relieved of this burden. 

A function definition algorithm is a hody of code which 
specifies what action should take place in response to a given 
external stimulus. A function definition algorithm has several 
responsibilities. 1) It must validate the input parameters, 2) 
It must execute the logic of the function, 3) It must access the 
system state tables and update them appropriately to reflect the 
action taken, and 4) It must provide an external response repre- 


senting the action (or lack thereof) that has taken place. A 
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function definition algorithm usually ineludes a series of calls 
to the ADT modelling subroutines. 

One integral part of ADT is a set of procedures which faci- 
litate the modelling of the "system state". These procedures 
provide the capability to create and maintain a network 
structured database which holds the entities, attributes and re- 
lationships used to model the system. 

A functional model created using ADT can be exercised and 
"validated" by the creation and execution of a sequence of 
commands. (Calls to the various function definition algorithms.) 
Any number of commands can be executed so that the model can be 
ohserved in order to determine if it acts in accordance with 
expectations. 

Facilities are furnished in ADT to save these sequences of 
commands (scenarios) and to automatically execute them. There 
are also facilities so that the system state can be saved and 
restored. Display facilities are provided which permit a de- 
tailed examination of the system state without altering it. 
Using these facilities it is easy to construct experiments, alter 
them and examine the results at any time. 

ADT is a deterministic system, and the machine is always in 
a stable state during the period between calls to the various 


function definition algorithms. 


VIT.3 The Deadlock Detection Model 


The deadlock detection model which runs using ADT was de- 
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signed to be driven entirely by the user of the model. All the 
nodes in the network must be created by the model user, as are 
processes and database resources located at each node. In addi- 
tion all operators at each node must be declared. Each node in 
the network must have a unique name. Operator names and process 
names appear together in the same name space and must be unique 
within each node. They are qualified by the node name to make 
them unique in the network. Database objects must also have 
unique names within the set of database objects at a node. 
Process wait situations may arise as a result of requests 
for message text in a message group or over an operator connec- 
tion, or requests for access to a database object, but operator 
wait situations are not forced by the system hecause operators do 
not request message text, they only take it as it comes over an 
operator connection. All requests by processes for resources 
must be entered by the model user. The model will process the 
requests, and allocate the desired resources, if possible, 
otherwise the requesting process will be blocked. When message 
text is requested, the message group name (in the case of process 
to process communication) or operator connection name (for oper- 
ator to process communication) must be given. With the model, 
before message text in a message group can be received by a 
process, the message group must first be initiated by the process 
which can send the messages, and then be accepted by the process 
that will receive the messages in the message group. (The model 


user specifies when this takes place.) Actual systems may allow 
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message groups to be accepted by a process before another process 
initiates it. An operator connection must be established (by the 
model user) between an operator and a process at the same node 
before a process can receive message text over the operator con- 
nection. This model does not support the sending of messages 
from a process to an operator over an operator connection because 
typically messages from a process to an operator are not queued 
for receipt by an operator, they are simply printed at the 
operator's terminal without an explicit operator request. 

In order to make the model easier to use, it was decided to 
make message group names and operator connection names unique 
within the network. | 

In a computer network it is probable that message text may 
be sent by either process involved in a connection through which 
they are communicating. (This is a two-way connection.) The 
model only allows the initiator of a message group to send mes- 
sage text over the associated connection because a two-way con- 
nection can be simulated using two one-way connections, with each 
process involved being the initiator of one of the message 
groups. The sender and receiver of message text in a message 
group are thus uniquely determined by the message group name, 
therefore the model user need not type a process name when 
causing action to be taken to simulate the sending or receiving 
of message text. (Similarly, the sender and receiver of message 
text over an operator connection are uniquely determined because 


the model only allows message text to go from the operator to the 
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associated process.) 

Each node will need to maintain some information about the 
other nodes in the network. (It needs to know about remote pro- 
cesses that have requested access to at least one of its 
resources, and it needs some information about remote resources 
that have been requested by at least one of its processes.) The 
model is designed to create a set of node tables (one table for 
each node in the network) at each node in the network. Each node 
will use its set of node tables to maintain the information it 
needs about all the nodes in the network. 

Control messages are used by the model to simulate the 
transmission of most types of internodal messages. When a mes- 
sage must be sent between nodes, the model will cause text to be 
printed at the model user's terminal giving the model control 
message number and stating the destination node and what the 
message represents. At the time the model user would like the 
destination node to receive the message, he/she must issue a 
command to the model to receive the associated control message. 
ORPL's, message text within message groups, and resource 
allocation messages are all sent between nodes via control 
messages. This mechanism was selected so that the effect of 
internodal messages being delivered with varying delays could be 
simulated. The only internodal message that the model allows to 
be processed without user intervention is the one that would be 
associated with the initiating of a message group. There is no 


need to model the delay of a message for this because the node in 
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which the accepting process of the message group resides must be 
aware of the initiation before any checks for deadlock involving 
that message group will be made. 

The types of resource allocation messages that may pass be- 
tween nodes are 1) requests for access to remote database 
objects, 2) notification that a process has been granted access. 
to a previously requested database object, and 3) notification 
that a process has released a database object. If the model user 
enters a process request for a remote database object, the model 
will block the process and send a control message (representing a 
remote resource request) to the node in which the desired 
database object resides. (Since deadlock detection is being 
modelled, and resource allocation need not be completely 
simulated, the model first looks across nodes to verify that the 
requested database object exists before it sends the control 
message.) After this control message is received and the desired 
database object can be allocated to the aforementioned process, a 
control message stating that the process has been allocated the 
desired resource is sent to the node in which the process 
resides. When this new control message is received, the process 
will be awakened. Although the release of database objects is 
not necessary to test an algorithm for deadlock detection, a 
command to allow a process to release a single database object 
was included in the model for debugging purposes. When a process 
releases a remote database object, a control message is sent to 


the node in which the database object resides. The model does 
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not simulate the automatic release of all resources controlled by 
a process at the time the process reaches a commitment point. 
This is a feature of process and resource management, and is not 
relevant to the simulation of a deadlock detection algorithm. 

In order to create deadlock situations, processes must be 
able to gain control of some database objects. The model uses a 
first-in-first-out allocation scheme for database objects. A 
process will be blocked if 1) it requests any type of access to a 
database object that has been exclusively assigned to another 
process, 2) it requests any type of access to a database epject 
which already has other processes waiting for access to it, or 3) 
it requests exclusive use of a database object and some process 
currently has access to the desired database object. 

In order to adhere to the belief that the model should be as 
simple as possible, the model, in expanding an OBPL, does not use 
the decentralized algorithm exactly as described in the previous 
chapter. In step 10, the branch to step 3 was removed, thus step 
11 is always executed after step 10. When step 11 sends an OBPL 
to the node in which it is already located, further expansion 
takes place immediately. Steps 1 and 2 then get executed 
unnecessarily because RX is properly set in step 10, and the 
State tables have not been changed during the expansion of the 
OBPL so the last process to be inserted into the OBPL is still 
waiting for RX. This implementation was chosen to simplify the 
coding of the function definition algorithm used to expand 


OBPL's. 
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Appendix I contains a Data Structure Diagram for the 
deadlock detection model, plus a description of the entities and 
relationships shown in the Diagram. Appendix II contains a brief 
description of all the user visible functions in the model, fol- 
lowed by the PL/I code of the function definition algorithms 


which define the model. 


VII.4 Test Cases run on the Model 

Using the model, several deadlock and near deadlock 
situations were entered to demonstrate various features of the 
deadlock detection algorithm. A feature of the ADT system allows 
a user to save a series of commands in a file, and then type 
"scenario <file name>" to have the commands executed in order. 

In each of the cases given, after the system was reinitialized, 
but before the commands specific to each example were executed, 
the commands in file "demo0O" were executed. The files, along 
with the output that resulted from the commands in the files, 
appear in Appendix III. The scenarios are well annotated, and it 
should be noted that commands to the system appear flush with the 
margin, whereas output from the Deadlock Detection Model is 
indented. 

The deadlocks created range from one involving two processes 
and two resources located in a single node, to some involving 
more than five processes or operators and more than four 
resources located throughout a three node network. By creating 


the same deadlock, but altering the order in which processes get 


T2 


blocked and the order in which internodal messages are allowed to 
arrive, it is shown that the number of times the same deadlock is 
detected depends on how close (in time) some processes in the 
deadlock get blocked, and on the locations of the various pro- 
cesses and nodes. (The model works properly regardless of the 
"simultaneous" processing of commands at various nodes.) Appen- 
dix III also includes state diagrams for the test cases which 
appear in that Appendix. For the cases where a deadlock is cre- 
ated, only the final state is drawn (a key to understanding the 
diagrams is included), whereas for the cases where there is no 
deadlock, an important interim state is included in addition to 
the final state. 

The restriction stated in Chapter 4 that a process can not 
gain access to a database object, release it and request it again 
before reaching a commitment point, was included to rule out the 
Situation that is shown in "demo bug". (The scenario was 


included for demonstration purposes only.) 
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VIII. Suggestions for Further Research 

After a deadlock is detected, at least one involved process 
must be forced to rescind its request for a resource that is 
controlled by another process involved in the deadlock. Some of 
the problems involved in breaking a deadlock (in particular when 
the deadlock is detected using the decentralized algorithm 
presented in Chapter VI) are discussed below, as are some issues 
that may lead to modifications in the sehemes presented in 


Chapters V and VI. 


VIII.1 The Rollback/Retry Problem 

In order to break a deadlock situation, at least one process 
involved in the deadlock must be selected and be forced to 
rollback (backup) to a state prior to the time at which it re- 
quested access to the resource for which it was waiting when the 
deadlock was detected. If the algorithm presented in Chapter VI 
is being used to detect deadlocks, then (due to the restriction 
that a process cannot release a database object when it is be- 
tween commitment points) the process selected for rollback must 
be returned to its most recent commitment point. In rolling back 
the process, the external effects created since the last process 
commitment point must be cancelled. 

To accomplish this rollback, it is necessary to undo all 
datahase object updates that the process performed within the 
scope of its current commitment unit (the period since its most 


recent commitment point), and then release all the database ob- 
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jects that were assigned to the process. In addition, all items 
of message text that were sent by the process in this commitment | 
unit must be taken back, and all items of message text that were 
received by the process in this commitment unit must be requeued 
over the proper connections so that they may again be properly 
received after the process resumes execution. When taking an 
item of message text back, if it had already been received by the 
destination process, this destination process must .also be rolled 
back to its most recent commitment point. . 

Research needs to be performed to determine an efficient 
method for rolling back a process. It is possible that some 
constraints may have to be placed upon communicating processes in 
order to simplify the rollback problem and lessen the amount of 
information about a process that must be retained between 
commitment points. Some — have been published that deal 
with the problem of rolling back a database to a previous state. 
(See cH) for one example.) . 

Use of the deadlock detection algorithm described in Chapter 
VI can result in the same deadlock being detected more than once. 
It therefore may be useful to develop a deterministic algorithm 
for deciding which process should be rolled back, so that addi- 
tional processes are not rolled back unnecessarily. Note that if 
ORPL's are dvleated immediately after a process gets blocked, then 
every deadlock will be detected with an OBPL that contains only 
the involved processes. Thus even though a process not involved 


in a particular deadlock may be waiting for access to a resource 
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which has been assigned to a process in the deadlock, no action 
need be taken when the deadlock is detected using an OBPL which 
contains more than the involved processes. One possibility is to 
impose an arbitrary ordering on the nodes in the network, and 
always rollback a process in the lowest numbered node that is 
involved in a given deadlock. This method is unfair in the sense 
that processes in the higher numbered notes will rarely be forced 
to rollback to a previous state. Perhaps a fairer method is to 
attach a cost factor to each process entry in an OBPL. This cost 
factor will represent the cost (for the associated process) of 
computation to date in that process commitment unit. The process 
with the lowest cost factor will be rolled back with the hope 
that this minimizes the overall network cost of breaking the 
deadlock. It is also possible that when the same deadlock is 
detected more than once, it may be cheaper (from the overall 
network cost viewpoint) to rollback an extra process 
occasionally, than to add the extra overhead that is needed for 
the methods mentioned above. This is a topic which needs to be 
studied further. 

Another related topic which can be investigated involves 
relaxing some of the restrictions dealing with the release of 
database objects so that a process can be rolled back to a state 
somewhere between the previous commitment point and the deadlock 
state. This may involve slight modifications to the algorithm 
described in Chapter VI, but may be useful because less code will 


have to be reexecuted after rollback. (It may be particularly 
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worthwhile when a process is executing a section of code where it 
is sequentially requesting access to several database objects 
before reading or updating any of them. Thus a partial, and 
perhaps sufficient rollback could be accomplished by the release 


of some of the database objects.) 


VIII.2 Optimization and Expansion of the Decentralized Algorithm 

If OBPL's are created after a process has been blocked for 
'X' units of time (with 'X' greater than 0), then it may be pos- 
sible to occasionally eliminate the need to create an OBPL after 
a given process has been blocked for 'X' units of time. When a 
process is inserted into an OBPL before it has been blocked for 
'X' units of time, the need to create an OBPL with this process 
as the first entry is eliminated. (Additionally, the process may 
be granted access to the desired resource before 'X' units of 
time have elapsed, also eliminating the need to create an OBPL.) 
This type of implementation would affect the scheme used to break 
deadlocks, as there would no longer be the guarantee that each 
deadlock would be detected with an OBPL that only contains pro- 
cess entries for the involved processes. 

A restriction presented in Chapter IV prevents a process 
from requesting shared access to a database object and then 
requesting exclusive use of the same database object. It may be 
possible to allow this situation will little modification to the 
decentralized algorithm. 


The algorithm presented in Chapter VI requires that all 
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resources be uniquely identifiable. It may be desirable in some 
applications to allow processes to wait for any one of N 
identical and interchangeable resources. Inclusion of this 
property would necessitate a change in the use and expansion of 
ORPL's. Preliminary study shows that it would be necessary to 
place control of the expansion of an ORPL with one node (which 
may be different for each ORPL), since notification would be re- 
quired after it is ascertained that a loop exists in an OBPL or 
that an active process has been encountered. This notification 
is needed because there is a deadlock involving N identical 
resources only if every process that controls one of these 
resources is involved in a loop in an ORPL. (This is in contrast 
to the situation where there are N readers of a given database 
object and a deadlock exists if any one of these readers is 
involved in a loop in an ORPL.) Rather than passing an OBPL from 
node to node, the “eontrolling" node may request other nodes to 
expand a section of the OBPL and return it to the "controlling" 
node. Further study is required to determine exactly how the 
decentralized algorithm can be modified to include the above 
mentioned feature. 

In addition, it may be worthwhile to study the possibilities 
of allowing human processes to wait for events external to the 
computer system (i.e. a phone call or a message from a fellow 
worker, rather than only wait for a message from a given process) 
and/or the possibilities of allowing a process to wait for more 


than one resource at a time. 
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VIII.3 Types and Probability of Deadlock 

In order to get a valid estimation of the cost of using the 
deadlock detection algorithm presented in Chapter VI, it is nec- 
essary to get estimations as to how many processes in how many 
different nodes are typically involved in a deadlock, and how 
frequently deadlock can be expected to occur. Some research has 
been performed dealing with the probability of deadlock in a 
computer system (see [6]), but to this author's knowledge, no 
work has been performed dealing with the types (i.e. how many 
processes in how many different nodes) of deadlock that can be 


expected in a computer network. 


VITI.4 Refinement of the Centralized Algorithm 

The scheme presented in Chapter V was not studied 
extensively. It is possible that it can be refined to a point 
where little, if any, unnecessary processing takes place in order 
to determine if a deadlock exists. Due to reliability factors 
and communications delays, it is not recommended that a 
centralized scheme be used exclusively in a network. However, a 
hybrid model of the centralized and decentralized algorithms may 
prove to be more cost effective than the decentralized algorithm 
alone. This hybrid model could possibly be constructed by using 
the centralized scheme for small groups of nodes located within a 
specified distance of each other, and then using the 
decentralized scheme between the control nodes for each of the 


groups using the centralized scheme. 
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IX. Conelusions 

The schemes presented in Chapters tI and III were designed 
to be used to help detect process deadioeks: in & computer network 
where the only sMowable wait condition: ase4er: the availability 
of database resources. Many systeme: only allow this type of 
process wait, so there is a need for algorithms ‘which solve the 
problems that the schemes of Crapters: Tur wads T11 attack. 
However, some alterations must be made to the scheme of Chandra, 
Howe and Karp and tothe decentralized schene of Mahmoud and 
Riordon before they ean be used to Sbive: the brodlems they 
address. It seems: that these two. sehenes, - when - modified, would 
result in essentially the same aigorithn. This. new algorithm 
would require each node's resource tabaes- to be sent to one node 
in the network, which will then proeess ali the outstanding 
requests for access to database objects. (In the case of Mahmoud 
and Riordon's scheme, perhaps each node would still examine all 
requests.) The major difference from the original schemes is 
that no resource allocations would be performed without examining 
the entire network state. (i.e. requests for access by a process 
to local resources must still wait for information from other 
nodes) With or without modifications, the two schemes are 
inefficient in that they require large tables (when the database 
is locked at the record level) to be passed between the nodes. 
Additionally, each node must be capable of processing requests 
which require the presence of every node's tables in that node. 


This is an undesirable constraint, because it requires 
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minicomputers which serve as nodes within the network to have the 
capacity to store (in main memory or secondary storage) the 
entire network state at one time. Although only minor modifica- 
tions are required to the schemes so that they will work, they 
may require some major modifications before they can be used in a 
general scheme for detecting deadlock in all types (i.e. any size 
computers and any number of nodes) of computer networks. 

The two "centralized" schemes presented in Chapters III and 
V can both result in message bottlenecks at the control node, and 
if the control node fails, both result in a significant delay 
while a new control node is established. Additionally, if the 
network is geographically spread out, there can be an undesirable 
delay in some cases when a process requests access to a local 
database object. It is recommended that neither scheme be used 
exclusively in a network which covers a large (geographically) 
area or consists of a large number of nodes. 

The decentralized algorithm presented in Chapter VI requires 
each node to only maintain information relating to its processes 
and resources. Thus the amount of storage required at each node 
to support the algorithm is proportional to the total size of the 
system at that node. Additionally, there is little, if any, 
delay in granting a process access to an available resource. 

The size of messages (OBPL's) passed between the nodes is 
directly proportional to the number of processes involved in a 
chain, where each process is waiting for a resource controlled by 


another process in the chain. It is felt that these chains (and 
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therefore OBPL's) each involve only a few processes, and by 
delaying the creation of OBPL's until after a process has been 
blocked for ‘Xt units of time, the number of OBPL's that must be 
passed between nodes will be minimal. It should be noted that 
the decentralized algorithm presented in Chapter VI will work 
regardless of whether or not processes are allowed to wait for 
messages which must be sent from other Con eenes within the net- 
work. - 

With the optimization feature discussed earlier, the algo- 
rithm presented in Chapter VI is efficient and ean be use 


regardless of the size and composition of a computer network. 
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Appendix I ; Entity Descriptions 


This section describes the entities which are used in the ADT Deadlock 
Detection poder. Each entity is described in basically the same manner. The 
ormat used is: : 


spare NAME> 
<text 


entity attributes: 
<attribute name> 
RE ORG oi6b eck Wess 


eeeseoseneseeosesers 


entity owner roles: 
Sneee of set owned by entity> 
t @eeoeeeseeee 


entity member roles 
<name of set where entity is a member> 


The sets are named in the following \ way: 
owner_nane->member_nase 
Both owner_name and member_name are the names of entities. A qualifier is 
used to distinguish between two sete which ‘heave, the ‘ane entities’ as owner and 
menber: 
owner_name->nember_name( qualifier) 
If there are alternate owners or sultiple members, the notation used is: 
owner _name/owner_nane/ oe .~>member_name/menber_nane/. . oo Where attribute 
names are used, they correspond exactly to the names (which include, abbrevia- 
tions for the entities they represent) that are used. in the PL/I code anf the 
Model. 
DATABASE Dbsect 
a eritey ce an object within the database whith is subject to exclusive 
DeaiJurite or shareable (read only) access control. The object may be of 
various levels of granularity (file, Fecord. of .3h “of: ord}. The 
only requirement is that the entire 'o ae * ‘yin regard 
to assignment to a process and. subsequent. release. ee 
eae aty attributes: 
dbo. nage 


The unique name for the database ob ject’ at the node in which it 
resides. 


entity owner roles: 
da abase_. SHE acannon, shared assisn va abase object defining 
the némber of proeea: rien: Y aarkag tee ae jase Object on a 
read-only basis. 


database_object->process 
tec set of processes waiting on the awailability of the database ob- 
ec se 
see node . table/dbo/message_group/operator_ connect ion->process) 
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entity member roles: 
node_table->database_object 


process->database_object 
DATABASE_OBJECT_SHARED_ASSIGNMENT 
The mechanism for recording the shared assignment of a database object to a 
process for read only purposes. 
entity_attributes: (none) 
entity owner roles: (none) 


entity member roles: 
database_object->database_object_shared_assignment 


process->database_object_shared_ assignment 


MESSAGE_GROUP 
The string of text elements which are sent from one process to another over 
a specified connection. 


entity attributes: 
message .name 
The network unique name for the message group. 


message .number_qd 
The number of messages in the message group that have been received 


by the acceptor of the message er plas | number of nessages that 
are cuenentsy queued at the destination end and have not yet been 
received. 


message .number_rcvd 
The number of messages in the message group that have been received 
(read) by the acceptor of the message group. 


message .number_sent 
The number of messages in the richtig group that have been sent 
(regardless of whether or not they have currently reached the desti- 
nation node) by the initiator of the message group. 


entity owner roles: 
message_group->process 
The set o peovesses waiting for text in the message group. The na- 
ture of exclusive assignment of a message group to a process 
iad acting more than one process to actually be wait for text. 
see node_table/dbo/message_group/operator_connect lon->process) 


entity member roles: 
node_table->message_group( accept) 


node_table->message_group(init) 

process->message_group(receive) 

process->message_group( send) 

system->message_group 

MESSAGE_TEXT 

This represents one message within a econere group when the initiator and 
acceptor are located in different nodes. o actual text need be 
transmitted, because for the purposes of deadlock detection, the content of 


the messages is unimportant, and it is only necessary to know how many 
messages are sent and received. 
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entity attributes: 
msg.mg name 
The message group name to which the "simulated message" belongs. 


entity owner roles: (none) 


entity member roles: 
system->message_ text 


NODE 
A processor in the network which includes a Process Management Module for 
the purposes of resource allocation and deadlock detection. 


entity attributes: 
node .name 
The network unigue name for the node. 


entity owner roles: 
node->node_table 
The set of tables used by a node to maintain all needed information 
about the nodes in the network. 


entity member roles: 
system—>node 


NODE_TABLE 
A table used to maintain needed information about operators, processes and 
resources located at a given node. 


entity attributes: 
node_table.name 
ene name of the node about which this table will maintain informa- 
on. 


entity owner roles: 
node_table->database_object 
The set of database objects located in the node "referenced" by the 
node table, and for which the node in which the node table resides 
needs information. 


node_table->message_group( accept) 
The set of message groups that have been initiated with the accepting 
procese declared to be located in the node which is "referenced" by 
he node table, and located therein. (If a node table does not 
"reference" the node in which it is located, then this set is empty 
for that node table. ) 


node_table->message_group( init) 
The set of message groups that have been initiated by rocesses lo- 
eated in the node which is "referenced" by the node table, and lo- 
eated therein. (If a node table does not "reference" the node in 
which it is located, then this set is empty for that node table.) 


node_table~>operator 
The set of operators declared to exist at the node "referenced" by 
the node table, and for which the node in which the node table re- 
sides needs information. A node only needs to know about the oper- 
ators at its own node, therefore if a node table noes not "reference" 
fasion}. in which it is located, this set is empty for that node 
able. 


node_table->process 
The set o rocesses located in the node "referenced" by the node 
par Sa ene or which the node in which the node table resides needs 
nformation. 
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node_table/dbo/message_group/operator_connection->process 
The set of processes in a particular state. If the owner is a 
node_table which "references" the node in which it is located, then - 
the process is in the ready or running state. If the owner is a 
database op ieee: the the process is waiting for access to that 
database object. If the owner is a meoerte group or operator con- 
nection, then the pecoess is waiting for text in that message group 
or over that operator connection. 


entity member roles: 
node->node_node_table 


BPL 
An ordered blocked process list used to detect deadlock. 


entity attributes: 
obpl.res_name 


The name of the resource for which the most recently inserted process 
into the OBPL is waiting. 


obpl.res_node_name 
The name of the node in which the above mentioned resource resides. 


obpl.res_type 
The type (database object, message in a message group, or message 
over an operator connection) of the above mentioned resource. 


obpl.masg_ numb 
If the above mentioned resource is a message in a message group, then 
this attribute contains the number of the message (within the message 
group) that is being waitied for. 


entity owner roles: 
OBPL=~>OBPL_process_ent 


ry 
cueroer of processes and operators that have been inserted into the 


entity member roles: 
OBPL_pass=>0OBPL 


operator->0OBPL 


OBPL_PASS 


This is used to pass an OBPL from one node to another, where it can be 
further expanded. 


entity attributes: 
obpl_pass.des_node_name 


The name of the node to which the OBPL is being sent for further 
expansion. 


entity owner roles: 
OB ass->OBPL 


s is a one-to-one relationship with the member being the OBPL 
that is being passed from one node to another. 


entity member roles: 
system->OBPL_pass 


OBPL_PROCESS_ENTRY 
This represents a ppocess that has been inserted into an OBPL. 


entity attributes: 
proc_entry.node_name 


The name of the node in which the process that has been entered into 
the OBPL resides. 
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proc_entry.process_name 
The rene oF epgname that has been entered into the OBPL. 


entity owner roles: (none). 


entit _Beaber roles: 
' OBPL-~>OBPL_procesa_entry 


OPERATOR 
This entity represents a person that has: been t dechared as an operator at a 
given. node. 


entity attributes 
operator .name 
aae 1nsaye nase for the operator. in the node at which he/she is lo- 
cated. 


entity owner roles: 
operator~>0BPL 
The set of OBPL's that pequire state: {nforeation about: the operator 
before they can be further aepence?: 


operator~>operator connection 
The set of operator Gounectious over which: the apanaten ‘may 
communicate with processes. 


entity member roles: 
node_table->operator 


OPERATOR_CONNECTION 
An entity via which messages are sent akg an orereter to a process. 


ate onttributes: 
yore betwen unique name for the operator connection 


oO -Bumbder 
: e number | 3 messages that have been sent by the operator but have 
not yet been received by the process over this operator connection. 


entity owner roles: 
operator_. connect ion->process 
The set of processes waiting for text over the operator connection. 
The nature af usive of -an. operator donnection to a 
process precludes more than one process ats actually be waiting for 


see node_table/dbo/message_group/operator_comnect ion->process ) 


entity member roles: 
operator-Soperator_connect ion 


process->operator_connection 
system->operator_connect ion 


sae (PROCESS raphe inh UNIT) 


ge iy proosas which ia execut: with: conmitment 
vate t (te tod vecuean process Scent tmente a proceuses 3 are unique, 


ede process commitaent units, therefore t model treats then as one 
entity. 


entity attributes: 
process.access_type 
the process is waiting for access to a database object, this at- 
tribute denotes the type ("shared" or "exclusive") of access desired. 
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rocess.name 
P The unique name of the process within the pode in which it resides. 


entity owner poles 
regese->debatas bje 
The set att objecta currently ¢: vely assigned to the 
recess fe tor r we o purpores. f a da ee Bb ject. is not 
ns: euch. s 
dat Seana ab iat pdetetane: tease aet is empty, then 
it is available fer exclusive ses: at, 


ovset of databace objec 


: aay tesrpect tes 
database objects assigned & process on a shared only) hacia: 
progess—>sessage_sroup(recsiv 


ot of pesaage groups Shieh ‘Reve: aceepted by the Gace 
The process can receive messages in meepege groups. 


progess->aea oup( send) 
The set oF a ay veieh have beso daitiabed bp: che process: 
AIEEE oo rete 9 
progess- >eperator_ connection 


e set of apetetor eonnect ions over wien the process can receive 
mesnages frog operators. 


entit roles: 
Able teblecseneeasé 


node_table/dbo/measege_group/operator_connect ion=>process 
Sone interns al message ranting a procesa access to a database object lo- 
cated at a different t note. 
entity ahah pail ntn dy 


rea,grant .proc_nase a 
joe e naan © the process that is being given secege to a database ob- 


res_grant.proc_nodde_nase 
the nase of the node 1 in which the above wentioned process resides. 


pane of the, eocapeee objent. ‘whteh the shove mentioned process is 
eainig access to 


‘the name of the’ node in which the shove mentioned database object 
resides. oe Pe 
entity owner roles: (none) 


entity member roles: 
system->resource_grant 


RESOURCE, PBLEASE 
e internodal meorage etating that a. given database obgect has been re- 
jeased by a specifi process. | 


ats Re rte 
es_rel.des be name 
The name of the database object being released. 


res_rel.dest_node_ name 
The anes OF the node in which the releaped database object resides. 
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res_rel.rel_pnode_name 
he name of the node in which the process releasing the database ob- 
ject resides. 


res_rel.rel_proc_name 
e name of the process releasing the database object. 


entity owner roles: (none) 


entity member roles: 
system->resource_release 


RESOURCE_REQUEST 
The internodal message in which a process requests access to a database 
object located at a different node. 


entity attributes: 
res_req.access_ type 
he type of access ("shared" or "exclusive") that has been requested. 


res_req.dest_dbo_name 
The name of the database object to which access has been requested. 


res_req.dest_node_name 
e name of the node in which the desired database object resides. 


res_req.req_node_name 
The name of the node in which the requesting process resides. 


res_req.req_proc_name 
The name of the process requesting access to the above mentioned 
database object. 


entity owner roles: (none) 


entity member roles: 
system—>resource_request 


SYSTEM 
The computer network. 


entity attributes: 
system. las’ cont 256 
fee herria of internodal control messages that have been sent in the 
network. 


entity owner roles: ; 
system->message_group 
ane ore of message groups that have been initiated throughout the 
network. 


system->message_text/OBPL/pass/resource_grant/resource_release/ 
resource_request 
The set of control messages that have been sent, but have not yet 
been received by the destination node. The t pe of control message 
represented is uniquely determined by the entity type of the member. 


system->node 
The set of nodes in the network. 


system->operator_connection 
ane nil of operator connections that have been declared within the 
network. 


entity member roles: (none) 
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The ADT Deadlock Detection Mode] consists of seven PL/I procedures, each 
of which contains multiple entries. A deseription of the Deadlock Detection 
Model user visible functions begins on the next page. Ineluded in the de- 
seription of a funetion is the name of the prosedure. im which that function 
appears. The seven PL/I procedures follow the funetien deseriptions, and 
these procedures are followed by the two PL/I include files whieh are used by 
the various procedures. File DDM_serv_routines contains declarations of 
Deadlock Detection Model functions which are oalied by other functions within 
the Model, and file ADT primitives contains declaretions of the ADT system 
functions. 

The following is an index to the PL/I procedures and include files. 


OO ee ase aan 


1 

1 

roe 15 

ae ‘ 1 
REL 1 
REQ 1 
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USER VISIBLE FUNCTIONS 
ADT Deadlock Detection Mechanism 


acceptmg(p_mg name, p_accept_node_name, p_accept_proc_name) 

Declares process "p_accept_proc_name”™ located in node 
"py accept_node_name" as the only process that can receive messages in the 
message group specified by "p_mg@ name". acceptmg is located within procedure 


edbo(p node_name, p_dbo_name) 

Creates” a database object at the node specified by "p_node_name". The 
database object has a "local™ name specified by "p_dbo_name”™. cdbo is located 
within procedure DDM. 


reates" a node with the name specified by "p_node_name". cnode is lo- 
cated within procedure DDM. 


copeon(p_con_name, p_con_node_name P_op_name, p_process_name) 

"Creates" an operator connection between operator "p_o ame" and process 
"p_process_name", both located in node "p_con_node_name". e operator con- 
nection will have the global name specified by "p_con_name". copcon is lo- 
eated within procedure OP_CON. 


cnode(p node_name) 


GPrOct p-ncae Dees. p_process_name) 

"Creates" a process with the name specified by “p_process_name"™ and lo- 
cater 2 the node specified by "p_node_name". eaproc is located within proce- 
ure ‘; 


delop(p_op_node_nane, p_operator_nane) 
"Declares" that an operator with name "p_operator_name" exists at the 
node with name "p_op_node_name". dclop is located within procedure DDM. 


initmg(p_mg name, p_init_node_name, p_init_proc_name, p_accept_node_name) 
Declares process "p_init_proc_name" located in node "p_init_node_name" as 

the only process that can send messages in the message group specifi by 

"p mg name". All messages in the message group will be sent to a process in 

‘ e noes specified by "p_accept_node_name". initmg is located within proce- 

ure ‘ 


opmse(p_co 5. ) 
"Sends" a message from the ope rern to the process in operator connection 
"p con_name*®. opmsg is located within procedure OP_CON. 


opstat(p_op_node_name, p_op_name, p_state, p_con_name) 

States that operator op_name" at node mp0 pode pane: is either 
"active" or "waiting" (specified by "p_state"). If the operator is waiting, 
it would like to receive a message from the process in operator connection 
"py con_name". opstat is located within procedure OP_CON. 
revem(p_cont_ssg_numb) 

Causes the control message with number specified by "p_ cont_msg_ numb" to 
be received by the spprope.sve node and the required action then takes place. 
revem is located within procedure RCV_CM. 


revmsg(p_mg_name) 

uses a message to be "received" in message group "p_mg name”. If no 
Messages are queued, then the receiving process is blocked. rcecvmsg is located 
within procedure MSG. 


revopmsg(p_con_name) 

Causes a message to be "received" by the process in operator connection 
"py con name". If no messages are queued, then the process is blocked and we 
request the status of the operator involved with this operator connection. 
revopmsg is located within procedure OP_CON. 
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sendms (p 
is \oaptes within 


a Epeeoeee in are HOG message group specified dy “p_mg name". sendasg 


eates® (sptetanises) the systen. is Jopated within procedur 
DDM. CTebenatsy it alse #ec the com ml 7 : i 
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4: 
DbM: procedure; 
# This procedure is a collection of subroutines which either 
creates entities needed to model the deadlock detection algorithm proposes 
by Ferry Goldman or performs services for other routines used in the model. 
The following user visible functions are included: 
CREATE DATABASE OBJECT 


CREATE SYSTEM 
DECLARE OPERATOR 
The Forewing, su port routines are included: 
DECLARE DATABASE OBJECT 
DECLARE DATABASE OBJECT SHARED ASSIGNMENT 
DECLARE CONTROL MESSAGE 
DECLARE NODE TABLE 
DECLARE OBPL 
DECLARE pert CONTROL MESSAGE 


SS_ENTRY 
DECLARE REMOTE RESOURCE GRANT 
FIND ENTITY LOCATION 
INITIATE OBPL #/ 
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Zinclude ADT pe itives: 


cont_msg_numb pp bin: 
dboref binl17); 


e038 wt 
exp_obpl entry fixed BeOS ohap(12)); 
meassagecnumb "oh ak 


noderef fie ce 


prattr. cless_nane 

p_cont_msg_numb 

PAAbO_same ame 

udek cont nag esg_numb 

podel-entieys ty_cless_ name 
ode ame 


proc_teraret 7 
p_send_node_naene 
) pat 


write list_ fansivartabie); 
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Appendix II Procedure DDM 


/*# CREATE DATABASE OBJECT 5/21/76 */ 
create_database_object: cdbo: entry(p_node_name, p_dbo_name); 
if find entity_Ioc noderef, "sys->node", SYS_REF, p_node_name, "node.name") 
en do; 
eall write_list_("Invalid node name. ", p_node_name, 
does not exist."): 
cerns 
end; 
eos = find,entity loa(tableref, "node->node_table", noderef, p_node_name, 
node_' 


2 able name. 1 
if trod entlty.+00 dboref, "node->dbo", tableref, p_dbo_name, "dbo.name") 
en do; 

call write_list_("Duplicate database object name"); 
return; 
end; 

call del_dbo(dboref, p_dbo_name) ; 

call insert_(dboref, "node->dbo", "first", tableref); 

call write_1: ae ueeteene object bert p_dbo_name, " ereated in node ", 
p_node_name): 

return; 

/*# CREATE NODE 5/19/76 */ 


create_node: cnode: entry(p_node_name); 
if owner: (SYS_REF, "sys->node") 
en do; 
call write_list_("Illegal request, system has not been created."); 
return: 


end; 
eall find_first_(noderef, "sys->node", SYS_REF, no_more_nodes); 
do while no_more_nodes); 
if extract_(noderef, *node.name") = p_node_name 
then do: 
eall write_list_("Duplicate node name"); 
return; 


end; 
call find_next_(noderef, "sys->node", no_more_nodes); 


end; 
call oreate_entity (nogeref, "node"); 
ute_(noderef, "node.name", "field", 12, p_node_name); 
call create_relationship_(noderef, "sys->node", "mem er"}; 


call create relationship (noderer, "node->node_table*, "owner"); 
eref, p_node_name); 
call insert ableref, "node->node_table", "first", noderef); 
We will now make this new node "aware" of the existence of all 

other nodes, and make all other nodes "aware" of this new node. */ 
sec_noderef = noderef; 
eall find next_(sec_noderef, "sys->node", no_more_nodes) ; 
do while (~ no_more_nodes): 

/* First create a table entity for the new node to be used by 
another node. # 


call del_node_table(tableref, p_node_name); 

call insert_(tableref, "node->node_table", "first", sec_noderef); 

/* Now create a table entity for an existing node to be used by the 
new node. 

sec_node_name = extract_(sec_noderef, "node.name"); 

call dcel_node_table(tableref, sec_node name); 

call insert_(tableref, "node->node_table", "first", noderef); 

eall find_next_(sec_noderef, "sys->node", no_more_nodes) ; 


end; 
call write_list_("Node created: ", p_node_name); 
return: 
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/# CREATE PROCESS 5/21/76 #/ 
create_process: apres: entry(p_node_name, p_process_name); 
if find ent ity _sec\ poder er, *sys->node", sts REF. p_node_name, "node.name") 
en do: 
eall write_list_ ("Invalid name. “, p_node_ name, 
dees not exist"): 
return: 


end: 
eos = find our ttya poet baieres: "node~tnede_table", noderef, p_node_name, 
.. node_Cable.name" ); 
if * find_entity_loc(preeref, "node->process", tableref, p_process_name, 
"process. name") 
then da; 
call write_list_("Duplicate process name"): 
eye 
end: 
/* If an operator with the same name has been declared at the node, 
print an error message and return */ 
if “find_entity_loc(opref, "nede-operator”, tableref, p_process_name, 
ps "operator.nane") 
en do; 
call write list_(p_process_name, "has been previously declared", 
: as an operator at node", p_nede_name); 
return: 


end; 
call del_procesas(procref, rocess_name): 
eall jasert. jpecore?, *node- ess", "first", tableref); 
call insert_(procref, "node/d /mg->process* , éviret®, tableref); 
call write Tist_("Proceas", p_process_name, ‘created in node", p node_name); 


return: 
/* ‘ ene SYSTEM : 5/18/76 #/ 
create_syst: csys: sysgen: entry; 
if SYS_REF “= 0 4 _— , 
then do: 
call write_list_("System already created"): 
return: 


end; 
call create_entity_(SYS_REF, "system"); 
call create_attri ute (SY REF "system. last_cont_msg", "field", 10, 0); 
call create_relationship_(SYS REF, "sys->node", "owner*); 


call create_relationship (SYS _ REF, "sys- *, *owner"); 
call create_relationship_ (SYS REF, "sys->con ssage" howner"); 
call create_relationship (SY F, “sys-ymessage™, “owner*) ; 


»_(SYS_RE 
call create _relationship_(SY REF; "sys~>op_con”, "owner" ): 
call write_list_("System created"): 
return: 


/*# DCL DBO 5/27/76 #/ 

del_dbo: entry(p_del_ref, p_del_dbo_name): 

/* This procedure creates an entit for a database object with name specified 
by "p_del_dbo_name"® and creates the necessary relationships. A reference 
to the entity is returned via "p,dcl_ref®. / 


te_(p gdel_ref, "dbo.name", "field", 12 cl_dbo_name) ; 
call create _relationship— p_del_ref, "process->dbo* Amenber™§o— 


return: 
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/# DCL DBO SH ASMT 5/27/76 */ 

del_dbo_sh_asmt: entry(p_del_ref) 

/* This procedure creates an entit for a database object shared assignment 
and returns a pointer to it via "p del_rer" / 

call create_entity (p del ref, "dbo_sh_asmt"); 

call create_relationship (p_del_ref, "process->dbo_sh_asmt", "member"); 

chet create_relationship_(p_del_ref, "dbo->dbo_sh_asmt", "member"): 

return; 


/* DCL CONTROL MESSAGE 5/27/76 */ 

del_control_message: entry(p_del_ref, p_del_entity_class_name, 

p_del_cont_msg_numb); 

/* This procedure will establish an OBPL, a remote resource request or a 
remote resource release as a control message. It will generate a control 
message number (which becomes an attribute of the entity specified by 
"p_del_ref*) and change the “Spaces entity so that it is aware of the 
new control message number. This control message number is returned via 
"py del _cont_msg numb" #/ 

p_de)_cont_msg_numb = extract_(SYS_REF, "system. last_cont_msg") +13 

eall alter_(SYS_REF, “system.last_cont_msg", p_dcl_cont_msg_numb): 

call create_order_(p_del_ref pdel_entity class_name, "control_message"); 

call create_relationship_(p del_re > "sys->control_message", "member" ); 

call create_attribute_(p_del_ref, "control_message number", "field", 10, 

‘ p_del_cont_msg_numb); 
return; 


/* DCL NODE TABLE 5/27/76 #/ 

del_node_table: gate pdel_ref, p_del_node_tabl_name); 

/% is procedure will create an entity for a node table and creates the 
necessary relationships. The ant tty is also given the name specified by 
np-Got noge—tap name", A pointer to the new entity is returned via 

p_del ref*., 

call create_entity_(p_dcel_ref, “node_table"); 

call create_attri ute _(p del_ref, "node_table.name", "field", 12, 


p_del_node_ta ; 
call create_relationship_(p_del_ref, wnode~>node_table", "member" ); 
call create_relationship_(p_ dol_ref, "node->operator", "‘owner"); 
call create_relationship_ 
call create_relationship_ 
call create_relationship_ 
call create_relationship_ 
call create_relationship_ 
return; 


p_del_ref, "node->process", "owner"); 
p_del_ref, "node->dbo", "owner") ; 

p_del_ref, "node/dbo/mg->process Fy "owner" ); 
p_del_ ref, "init_node->message", owner"); 
p_del_ ref, "accept_node->message", "owner"); 
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Gel, ob 1: Pontry( p_oppirer | qnam, pre 
do) obp ea oe a ee ee 
qntity will be of an comedy see the same, type. nene 


paraneter 
call creaté, 
call create 


call creste_yre 
oath create_rel 


al 
¢all oreaté 


/* Create og 7 only ened “te | reseersé: ts @ wessage) 
to indicate, the seasage nuaber’ “withie : mesonge woe that fs being 
wa 

call creat create_sterinate (nctyiret, *oupt aagsa, "T1616" , &, "OF); 


return: 


/* 

Il _obpi.. 

fa this @ pointe 
to by ~ the the 


eall Sreete, Mere Ca LOUpl. » ore Oa "field", 
call create Pelstionsnip, (ebpl, pesuret sooyl yeso-Derpi", "“owner*); 


call write P peed . 
return: ‘ 
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/* DECLARE OPERATOR 7/13/76 #/ 

dglop: entry(p_o6p_node_name, p_operator_name); 

/* is procedure will create an entity for an operator with name specified 
by "p_operator_name" and located at the node specified by 
"p_op_node_name" 

/* If the node specified by "p_op_node_name" does not exist, print an 
error message and return */— 

if find_entity_loc(noderef, "sys->node", SYS_REF, p_op_node_name, 

"node .name" 
then do; 
call write list_("Inmalid node name:", p_op_node_name, 
Wdoes not exist"); 
return; 


end; 

/# Get the location of the node_table for ap op node _name” #/ 

eos = find_entity_loc(tableref, "node->node table", noderef, 
PpP_op_node_name, "node_table.name"); 

/* If "p_operator_name" was previously declared as an operator, print an 

error message and return °/ 

if “find_entity_loc(opref, "node->operator", tableref, p_operator_name, 
"operator.name” 

then do; 
call write list_(p_operator_name, "has been previously", 
: "declared as an operator at node", p_op_node_name); 
return: 


end; 
/* If "p_operator_name* was previously declared as a process, print an 
error message and return */ 

if “find_entity_loc(procref, "node->process", tableref, p_operator_name, 

"process .name") 
then do; 
call write _list_(p_operator_name, "has been previously declared", 
A Was a process at node", p_op_node_name); 

return; 


end; 

/* Create an entity for the operator and declare the necessary 
relationships and attributes *# 

call create_en ity _(opref, "operator"); 

call create_attribute_(opref, “operator.name", "field", 12, picperator name) 

eall create_relationship_(opref, aoperecor oop oon "owner"); 

call create_relationship_(opref, "operator->obpl", "owner"); 

call create_relationship_(opref, "node->operator", "member") ; 

call insert, fopref, "node->operator", "first", tableref); 

eall write Tist_ p_operator_name, "has been declared as an operator", 

: at node™, p_op_node_name); 

return; 
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rate ent del_ref, p_del Hs name): 


DCL eeu 5/27/76 */ 
walt create n ent or a process, give it the name 
: ae and space’ the nevebeary 


relationships */ 


ier Spreeése.nane, "field", 12, 


. a 
»_ dc etree 
call create_attr pute fp in f, * ee. e6oeba type", "field", 10, °"); 
call create_relat Am p iol fer” Snegess weocess™ , Sheaber®);' 


call create_relat fp... PMcl ref, 


of 
res 
ec 
ted 
Oo! her § 
sick 


call create_relet + (p dol ref, } 
call create_rela jens a Bade jiref, Wi ioyner"); 
at etestecre cicaent = eaeererer’ | . owner") 
call crea sf @ i Pine ‘ 
eall create pelationshie’” PoGel-ref’ _pProe= Fa es’ , "owner*); 
return: oo ceca, ha hates 

ae DECLARE PR bead 

roc_entry? é pet 
ag This procedure wi 6 


The entity will be tuserted 
ae its roeees. name” pg ye 


call reate_ wtte (ores ryre 

oni Sanaa , 
1 6); sii: 

call create act rateeret, prea entry. née. pane; orseid®, 


call hance “ Uphae on oa fio i 1oLb1->proc_entey®, ae plobplref); 
return: 


/# DECLARE REMOTE RESOURCE GRANT 6/17/96 ey 
del_rem_res_grant: entry( coed neg p.. dbo_nane, p.proc_nede_nane, 


/* This orogedure 7 ‘oreate or: e eeeered napree allocation and 
then declare it as @ oortrol ne PEOe by 


call create_attri te rea,grant Fer, arene); ree_node_name", 
"Fielda* ’ (Be _neds_nase ) 5 
call create attribute’ (P f, "res_srant.res_name", 


call create attribute’ (Pem_grant ref, "rea_grant .proc_node_name", 


"Field", 12, pp » name): 
call create attribute, (pes grant yee, “res_grant. proo_name", 
"Field* p..process 


1 | name); 
eall del —control_sessage( ‘es_grant_ ref, *res_ grant", 


cal insert~ fa tegen te ref, "“sys->control_ message", "last", SYS_REF); 
return; 


162 


Appendix II Procedure DDM 


/* FIND ENTITY LOCATION 5/19/76 #/ 

find_entity_loc: entry(p_entity_ref, p_set_class_name p ownerref, 

p_entity_name, p_attr_class_name) returns(bit(1)); 

/* This PeccecuLe determines the database address of the entity with name 
"p_entity_name" (specified by the attribute "p_attr_class_name") which 
is a member of the set occurrence (designated by the parameter 
np-set_clags_name™) owned by the record occurrence designated by 

p_owne F 


If the desired named entity does not exist, a true value ("1") is 
returned and ng—gntity ref is unchanged. Otherwise a false value ("0"b) 
is returned and "p_entity_ref" is updated with the database address of 
the desired entity. #/ 
cert find_first_(temp_ref, p_set_class_name, p_ownerref, eos); 
eos 
then do; 
temp_name = extract_(temp_ref, _attr_class_name) ; 
do while (* eos & (p_entity_name = temp_name)); 
gal find_next_(temp_ref, p_set_class_name, eos); 
eos 


, then temp_name = extract_(temp_ref, p_attr_class_name); 
end; 


end; 
if “ eos then p_entity_ref = temp_ref: 
return (eos); 


/*# INITIATE OBPL 6/25/76 */ 

initiate_obpl: entry(p_proc_node_name, p_process_name, p_res_node_name, 

p_res_name, p_res ype ; 

/* This procedure will initiate the creation and orpene aon of an OBPL. The 
first process to be placed on the list is specified by "p_process_nane® 
and is located in the node specified at 4 "p_proc_node, name". The process 
is waiting for the resource specified by res_name™ and located in 
the node specified by "py res_node_name". The resource type ("dbo" or 
*"message") is specified by "p_res_type". #/ 

/* Create the OBPL entity and have it initialized with the resource and 
brccses information given by the parameters. */ 

cal del_obp1(obpirer p_res_node_nane, p_res_name, p_res_type); 

call del_proc_en (obp ref, p_proo_node_name, p_process_name); 

/* If the process is waiti for a message, then we must find out the 
message number (within the message group) that is desired and put this 
information into the OBPL. In addition, if the process and the sender 
of the message are in different nodes, then we must send the OBPL to the 
node which initiated the message group rather than try to expand 
the OBPL right away */ 

if p_res_type = "message" 

then do; 
/* Get the location 4 the entity for the rears group e/ 
eos = find entity_loc mgeref, "sys->message", SYS_REF, p_res_name, 
message .name"); 
/* Get the number of the message desired */ 
message mar = extract_(mgref, nmeasage .nuuber_qd°} + 1: 
call alter_(obplref, "“obpl.msg_numb", message_numb): 
if p coc nous nese = p_res_node_name 
en do; 
eail del_obpl_cont_msg(obplref, p_res_node_name, 
Pp_proc_node_name); 
return: 
end: 


end; 
/* Expand the OBPL as much as possible in this node *#/ 
call exp_obpl(obplref, p_res_node_name); 
return: 
end DDM; 
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REQ: procedure; 
/* This procedure contains the subroutine which allows processes 

to request database objects for shared or exclusive use. The following 

user visible function inoiuded: EOS, fate 2 ag 
REQUEST DATABASE OBJRCT # a 


del cont_msg@_nuab fixed bin: 
del dbo, : bows f. ' Bin } $ 
acl Soo tabieress fined Bint TT): 

ie ‘ 7 
del eos a ; pitt), 

c exe erret " a 3 
del nda_proc_ownerref 1333 
del p._access_ type 
del p_dbo nage «i: Ms, Bo 
del )_ Abo node name Aer 
del prio ay EPS. 
del p_process P ea 
del Pp. ae 
del ; $inG 17); 
del ptableref f n{i7); 
del res_req_ref kaea 
del oh aeeerer inGF7): 

write list_ entry options(variable); 
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/*# oe rad pletaeese BJECT 5/26/76 */ 
request_. » pyiba node rad sa ype, p_proc_node_name, p_process_name, 
/*y she battfied by Pap ame" exists */ 
if Hitt es caraeee sep otods SYS REF, p_proe_node_ name, 
le .name* 
ene oat write ii t_("Invalid od d 
call wr 8 nva ess node name. roc_node_name 
turn; “w4 joes not exist tBhy oP ' 
re ; 


/* Verify epei the process grecified by "p process name" exists at node 

eos = rin entity soot peableret gor pa sable®, pnoderef, 

if find_ent y_loc(p 4, : shode->precesst, -phanierer, ‘p_process_name, 
"proces 


3. heme 

then do; 
call write _list.("Invalid process: ‘neme" aye \ name, "at node", 
return: p.pree_node.name, “does: ‘not. oxic 


eri eee access t 1s s r “exolusiv 
ir (Pastesactype % nex pee, selene 2° eshared") 


pelt write list_ anes access type, requést ‘fot processed") ; 
return; . 


end; 

£8, Check if the process is blocked Me e 
ind_ocwuner_| cumercef, dbosn roces rocrel ); 

if entity elas neme_CacaL proc entree? nie set able" th 


1 | ’ 
> rest ’ fevalid re rome Scere" is sof Regs e 


es Check if the proness and urae.-are st ‘Soe oumr tote: e/ 


hen 9g The and resource are ‘at the same node */ 
entity that Tpeees dei abece object speci figd by by, "p_dbo_name" 


if wala Sroaesaber, phablerer;: pdbe_hane, 
es gaia write_list_ ("Invalid database. ject name.", 
Pabes"not axist. staal . pee Eene 
return; : 
{rinses ort § eho: has: Rg ers been assigned to the process*/ 
serted-{ "/0Che chee if; the process. has, exclusive control 
eall find owner_ entre caoubereer, Sprocess->dbo", dboref); 


if proore NS 
: call write ist (*1 valid request. Process", 
BLP name, "at node" 
Arps z ; “already has", 
exolusive control of*, p_dbo_n name, 
"at node", p:4de_ i_node_name) ; 


return; 
end; 
ent: 
else 
78 Check if the process has shared access to the dbo */ 
if ~ empty_intersection_(procref, "process->dbo_ sh_asmt", 
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dboref, “dbo->aba_sh_samt") 
O° 


oe pin ag pees for Fae ane #/ 


¥ the process if the database 0 patdert taeteee 
i ofber presaseng are surrect Sosued forthe” 


/* Check us the be recuest is or shared acosss */ 


lee . pet Ease Ses Fp Sve So Sm vie 


call insert 3 a poms (95 -# bas age ce 
call insert_(sh. stref, ESSE "first", 


(SThe next 1 Ai een tf the request is for 
xeclugive use of the database vot ong ba 
/* Cheek if any any process has shared access to the desired database 


if at (deoref, *"ddor>dbo_sh_seut*) 


ther 
PRaveve, tne he process for preieeiee wee of the database 
oO gee es poomuee e f her | 8 cyrrently 
. a. pees: *eeclusive™): 


nid ‘alter-( ioe feed. 1 pe. noowen type’, “e 
. *aode/c . ->process",” "last", 


gall a eee daceeiiee is sot ‘eurrently available" 
giusive ue, ee ir al ’ p-procesa name} 


oa, eee ee eee 
’ ame, 
i eaes nelggbeme.? 


pens: 
else do: /*Grant the process gxciusive use of the desired 
atabase object / 
call insert_(dboref, veromenac TORE": "first", procref); 
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call write _list_(p_procesa_name, fat node", 
ap Sis Seaers' pe exclusive use" 
Orn, ‘Pudbo_name, tat - pudbo_node_name} ; 


return: 
end; gett 
/* The jext Mggetion will be executed when @ process requests a “pamote 
resource . 


/* Verify fnat the desired database object exists #/ 
if find_enti ity Loot dpg.nederel, "“sye->node" ; : "SYS.REP, Pa poee pene: 


-name* 
then de: 
call write_list_ ("Invalid database object node name. ", 
p_dbo_node.name, "does not exist."); 


Pinal 
= fin eaisey gonlabe teats snode->p e_table", dbo_noderef, 
"*noda..table.n 
if te ting oof ee ve Wp nede-> aa: rai ableref, pdbo_nane, “dbo. naze") 
Sait writ ist_ valid database’ ‘object name » name 
aut ta, (ara dbo_node_nane, Seat name not mabe ; 
pid pally 
e0s = find_entity_loc(dbe_tableref, qnones72 de_table", pnoderef, 
p ode_name, "n table.name" 
/* eneck it we node scontainin oe ae 8 aware of the existence of 
da’ #6 0 
if fin entity 100 dbgref, enodersabo" tableref dbo_name, "dbo.name") 
then dos” Create, local lnbores don about the remote resource and 
. rocess. 


galt t wenatetdteret: @ ) dbo_name); 
insert_(dboref Prode=>dbo", *"first®, dbo . tableref); 
Gall alter_ rocess.access_type 2 ..access_type) ; 
eall reasvactprocret, node/dbo/mg—>proces 
cat insert_(procref, Misery ty ed tenet "last", dboref): 
en 
else do; /* Check if the database object has pean err been assigned 


r) 
otherwise block the pr 38. 
if dnsert: (dboref, "process->dbo" 


call core? rox _(exc_ownerref, "process->dbo", dboref); 
if proere z exc_ownerref 


art write _list_ {Stnvalid request. | Process", 
Pp_proc » “at node® 
“already has", 


)_P @_name, 
bepres tod control of", aba§?° ) name, 
"at node", p_dbo_node_n 


return: 
end: 
end; 
else do; . 
if empty_j gntersectic ion, { rocref, saa a 
th 2 ms sh_aimt 
en ° 


do; write_list_ ("Invalid request. Process", 
P- prod. i nuns nae eaeay has", 
Rchared soctes o*, Pp wt Fae 
Wat node", p_dbo_node_name 


return; 
end; 


end; 
/* Legal Bs vest, "block" the process. */ 
call alter_(procref, "process.access_type", p_access_type): 
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call remove_(procref, "node/dbo/mg->process"): 
cait insert. —{Precref! = "node/d bo/ag->proeess®, "last", dboref); 


call write to creat 2 x. ent » b..proc_node_name, 
a write li che notes 


: resource"); 

® Create an S53 ty For & FENCES TRRCETED FRGHNES Ome: declare it 
as a cent measage *°/ 

call create_enti' 


call dhe attri Sines =a socese..t ype", "field", on 
call createist ft, *pea_ree. da nene*, "field", 

eall crest EERIECIER Fee ret, trencroncren-geoeaen » "fieid*, 2 
call meiemsret nr "vea_reqvéest_pode_mame", "field", 12, 


= "rea_req.dest_dbo_nane", "field", 12, 
call , *eagegts: eee b): 

call ree 7G, t 6... . 

call < ° pent «, 
eall write_ - es *, : est"): 
return: reque 

end REQ: 
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%: 
MSG: procedure; 

/* This pe ccedure contains the subroutines which perform the 
message management functions for process to process communication within 
a network. he following user visible functions are included: 

ACCEPT MESSAGE GROUP 

INITIATE MESSAGE GROUP 

RECEIVE MESSAGE 


SEND MESSAGE #/ 
del accept_node_name char(12); 
del accept_node_tableref fixed bin(17): 
del accept_proc_name char(12); 
del accept_procref fixed bin(17); 
del cont_msg_numb fixed bin; 
del eos bit(1): 
del init_node_name char(12); 
del init_node_tableref fixe Bet): 
del init_proc_name ehar(12); 
del init_procref fixed bin(17); 
del messageref fixed bin(17): 
del aarer fixed bin iy ; 
del ndm_proc_ownerref fixed bin(17): 
del noderef fixed bin(17); 
del p_accept_node_name char(#); 
del p_accept_proc_name char(*); 
del p_init_node_name char(#); 
del p_init_proc_name char(#); 
del ) mz name ehar(*); 
del procref fixed bin(17): 
del rcev_msg_numb fixed bin; 
del send_msg_numb fixed bin: 
del write_list, entry options(variable);: 


Zinclude DDM_serv_routines: 
Zinclude ADT_primitives; 
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/* 5 shed pat agen GROUP eee AAS we ery 
acceptm entr ie name, p_ac pod e_rieme van bro 
7 ESEcobl ocetuart (edPinueta at'ebeeees meeltig oF 
acce n a , 
"p_acoept-nogecname™) will be apie" 


oe a tne message 
/* If the age. ‘peters 5 ys nese eer enist, ‘print 
if find rentity. _loclugret, “sys->message", SYS_KEP: psa ns 
: uesiage a - pie name 


then ¢ 
eail write list ("Invalid message group newe: ", p_mg name, 
ow does not t exist); oe : 
/* If the nessage SOUP has ghreedy. ‘Been accepted mS a + Deoaaae.. print an 
error mes return 


a 
if ea piyeica co 


end; 
° h te ; 6 no€ the adte 
/ If ere e node baveitin ta is aa tet 


if p_pccept node nase : ‘eatvact Ep taeatt vat ieee Besnane") 
eail seraienyoni ; 


call write _list_(" oO was 
¥ peauset is rejeéted ) 


Died ba 


/* if oe. rocess 8 ecified b accept_proc_nane" Be gata exist 
at beePecis® speci af igg by %, pseese Sept sioae name", print an 
if find entity... loc eeeepaerounar: snode->process® dias siete. tableref, 
chan Bsccep tuproc_ name, "process.name 
eall write, list_("Invalid process nase: cece , name, 
doesnot exist at node *, : peoebe Pade, 49 


return; 
end; 
/* If the process turn 87 "S the message group is not active, print an error 
message 
call f owner _ownerref, "n a ~> gs", accept_procref); 
if entity clase_feme_ nda_proc_ownerref aa on i’ 
en 


cail write _list_ ("Invalid acceptag yr ocess", 
‘p_accept_proc_name, is oe neki active" 
cna 


/* If the process Seger tang the message group is the | same one that 
1}"Findrowmer’ (Enig-node-tablersts init-gode-Suesaage", mgref); 
ca n owner. nit_node_tablere n e->ne8 ref); 
if init node_ mer (nls 2 accept_ node, . tablere is 
en do; 
/* The initiating and ecceee ane nodes are the same. o°2 if 
the initiating and accepting processes od the same 


call find_owner_(init_procref, seen etoe: yhessage", Scr): 
if init_procref’ = accept_procref 
en do; 


call write list_("Initiating and accepting | processes", 
Ware the same for message gre aad >» Pmg_name, 
"acceptmg command rejected 
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return: 
end: 
end; 
/* Insert the message group entity into the accept set for the process 
specified by ap -eocert_ proc name” * 
call insert, (ngre , "rev_proc->message", "first", accept_procref); 
call write lis —(P_mg_name, " has been accepted by ", p_accept_proc_name, 
: W at node "| p_accept_node_name): 
return: 


/* INITIATE MESSAGE GROUP 7/1/76 */ 
initmg: entry(p_mgname, p_init_node_name, p_init_proc_name, 
p_accept_node_name); 
/* This procedure will create a message group with the global name 
specified by "p_mg name". The only process that can send messages 
in this message group is specified by "p_init_proc_name" and is located 
at the node specified by "p_init_node_name".. The process that will 
receive messages in the given message group is located in the 
node specified by "p_accept_node_name". The specific process that will 
pore t the messages will be given in a subsequent call to "acceptmg" 
e user. 
/* a, we have a duplicate message group name, we must print an error 
message and return * 
if find_entity_loc(meret, "sys->message", SYS REF, p_mg name, "message.name") 
en do; 
eail write _list_("Duplicate message group name. initmg", 
. command rejected"): 
return; 


end; 
/* If the node specified by "p_init_node_name" does not exist, print 
and error message and return * 

if find_entity_loc(noderef, "sys->node", SYS_REF, p_init_node_name, 

"node .name" ) 
then do; 
call write list_("Invalid node name: ", p_init_node_name, 
does not exist"); 

return; 


end; 

/*® Get the location of the node_table for "p_init_node_name" *#/ 

eos = find_entity_loc(init_node_tableref, "node->node_table", noderef, 

p_init_node_name, "node_table.name"); 

/* If the process specified by "p_init_proc_name" does not exist at the 
node specified by "p_init_node_name", then print an error message 
and return #/ 

if find_entity_loc(procref, "node->process", init_node_tableref, 

ee p-init_proc_name, "process.name") 
en do; 
call write_list_("Invalid process name: ", p_init_proc_name, 
" does not exist at ", p_init_node_name); 
return: 


end: 
/* If the process specified by "p_init_proc_name" is not active, print 
an error message and return * 
call find_owner_(ndm_proc_ownerref, "node/dbo/mg->process", procref); 
if ea ae ndm_proc_ownerref) “= "node_table" 
en do; 
eail write_list_("Invalid initmg command. Process ", 
. p_init_proc_name, " is not active"); 
return; 


end; 
/* If the node specified by "pacoept_node_name" does not exist, print 
an error penener and return */ 
if find_entity_loc(noderef, "sys->node", SYS_REF, p_accept_node_name, 
"node. name" ) 
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then do; 
eall write_list_("Invalid node name: ", p_accept_node_name, 
does not exist"): 

pevurn: 

end; 
/* Get the location of the node_table for "p accept_node_name"™ */ 
eos = find_entity_loc(accept_node_tableref, qheger2nede cable’; noderef, 

p_accept_node_name, "node_table.name"); 
/* Create an entity for a message group, create the necessary relationships 

and attributes, and insert the entity into the appropriate sets */ 

call create_entity_(mgref, "message"): 
call create_relationship_(mgref, "sys->message", "member" ) ; 
call create_relationship (mgref, "init_node->message", "member") ; 
eall create_relationship (mgref, waccept_node->message" "member" ); 
call create_relationship (mgref, "send_proc->message", "member");  . 
call create_relationship_ (mgref, "rcev_proc~->message", wmember" ) ; 
call create_relationship_(mgref, "node/dbo/mg->process", "owner 5 
call create_attribute_(meref, nuessage.number_sent™, "tleld®, 4 QO"); 
call create_attribute_(mgref, "message .number_qd", "field", 4, "oO" i 
call create_attribute_(mgref, "message .number_revd" ®fiela", 4, "0"%); 
call create_attribute (mgref, "message.name", "field", 12, p_mg name); 
call insert_(mgref, "sys->message", "first", SYS REF); 
call insert_(mgref, "init _node->message", "hirst™ init_node_tableref): 
call insert_(mgref, naccept_node~>message" , first", mccep)_pede_tabierel): 
call insert_(mgref, "send_proc->message", "first", pecore . 
cell write_lis ("Message group ", omg name, "has been initiated"); 
return: 
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/* RECEIVE. MESSAGE es T/1/16 #/ 


revms ent me name 
/* this. > procedure i. simulate the, receiveing of a message in the message 
/@ FF the massage mag g spect peo ntl "p. mg name" does not exist, print 

r messag aay ant re - 


if find areniaty, ioteeret’ ey veye->uessage”, SY8_REF, pg _name, "message.name") 


cail write list. ("invalid myreeee group name: ", p_mg name, 
return; does not exist" 


/* aha ee oes 7 accepted the ciuesae arcue: print an error message 
return 
if Maserted (nerf, "rov_proc->message") 


gait ese pled (rInvalid rovmsg. command. No. process has", 
ae message group." p_me_nene); 


end; 
het ee the nae node a bree t ocess th : booie: poveiee, the message */ 
aces erat. Papert proge ypesange’, Rar 
f, "acce ried oar a ie meref); 
ghee tly Robent a n Sette, eran 
"acsept_proe_nemed . is Ro “aotive, print 


Ssrecrents.raptedebafeg. eceeese™ ‘accept_procref): 


” gail write, list, ("Process", accept., ene, “at node", 
a3 : ode. name, "is nog: pre pes "No wessage oan be"): 


eall ae receive san message group", p_m@g_name): 
ceneen: 


/* ging out itt the message can be eascivaa.: or if the. ‘process must 
e bloc 
rov_msg_numb * ‘Sxtract _tagret, "message number revd" 
if rev ms mb < extract “(ugref, "nessage.tumbe Bereades 
en 


7 ‘Allow the process: to Feseive the message #/ 


call ser trast we" rey. ag_numb) 5 
eall ie is vnc ; ge "s a 
cali Siva ifs seen a neseege” Con Lae group", p_mg_name): 


else do 
3 poe the seg e/ t," shaas e): 
call remove rocre mge->process");: 
call insert. ={eegept_prosrer! shode/dbo/me~ process", "first", 


eall write fi st, trrrocess, a: emer ae Nat: node", 


call write lis cme : ag: for, a g_name) 
a : : 
/* oe the name of the node thane ' itiaced Co ed tor? Ce cA} bee ueseané 


° 
cal "tind owner_(init_nod 9 "ini meref): 
init _node_) pane = extract etn itn aren node eeee ie nase’): 


/® Check ater Bont sosent 
eall inttiat obpl accept_node_name, accept_proc_ name, 
_node_name, p_mg name, eeeeeger 7) 


return; 
end: 
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/* SEND MESSAGE 7/1/76 */ 
sendmsg: entry(p_mg_name): 
/* This procedure will simulate the sending of a message in the message 
group specified by "p_mg name" */ 
/* e message group: specified by "p_mg name" does not exist, print 
an error message and return */ 
if ee Lentity_loc(mgref, “sys->message", SYS_REF, p mg name, “message.name") 
en do; 
call write_list_("Invalid message group name: ", p_mg_name, 
does not exist"); 
ea 


/* Verify that the process that should send the message is active %/ 
eall find_owner_ ctndap _procref, "send_proc->message", meref); 
eall find_owner roc_. ownerref, nod ¢/dbo/mg->process* , init_procref): 
if entity class | nane lade ones. ownerref) “s "node_table" 
en do: 
/* The process that should send the weorace is not pole: Get 
' its name and node and print an error ssage. .t 
call find_owner_(init_node_tableref, vintt. n “>nessage", meref); 
init_node_name = extract. Tnit_ node”. tableref, qnode_tey le.name") ; 
init_proc_name = extract_ nat ero orer ore *"process.name" 
call write _list_ ("Process " ame, “ at ghame . 
nit_node_name, "'is not active. ‘No message can be ba Be 
call write_list_(" sent in tessage group ", p_mg_name); 
return; 


end; 
/* Add 1 to nthe number of messages sent in this Benes a4 group a/ 
send_msg_numb = extract_(mgref, "mess e. number_sent* 
call alter_(mgref, "message .number_sen send_msg_nump); 
/* Find out if the messege must be sent "betwee es 
eall find_owner__ —finit— node _tableref, ig prt eh taken ere 
call find_owner accept _node_tablere pet -node->message mgref); 
if init _node_tableref “= accept_node_ LP 
en do; 
/*’Send a control message stating that a podeig has been sent in 
the message pe ue specified i apugenene” 
eall create_ent ty messageref, 
call create_attri ute rleessaceret, wae mg_name", "field", 12, 
p_mg_name) 

eall del. _control_mess e(mess agerot "msg", cont_msg_num umb) ; 

Call insert_(messagere a Maye control_pessage" » “last", SYS_REF); 

/* Get the names of the’ hd involved 

init_ prenode. ne = extract. (i it_node_ So iccat. epoca ati: name"); 


accept_node_name = extract, accep t noge_t tableref - 
"node_table.name®); 
eall write, list_ foonteo inossage number _? cont_msg_numb, 
® gent from ", init_node_name, " to *, accept_node_name) ; 
eall write_list_(" representing a message ina message", 
Wgroup"); 
return; 
end: 


/* If the next section of code is executed, then the message should be sent 
between processes at the same node */ 

/* The number of messages queued e uals the number of messages sent because 
there is no ta across any node 

call alter_(mgref 2 message .number_qd", send_msg_numb); 

call write_list_("A message has been sent in message group ", p_mg name); 

/* If no process has meat ects the pronenee group, return rather than see if 
a process should be woken up 

if “inserted_(mgref, "rev. Ponsa van shane 

then return: 

/* If a process is waiting for this message, wake it up and let it "receive" 
the message *® 

eall find_owner_ —fagcert. _procref, "rev_proc->message", mgref); 

call find_owner_(ndm_proc_ ownerref, "node/dbo/mg- aracess®. accept_procref); 

if ndm_proc_ownerref = mgref 
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e 


then do; 


return: 
nd MSG: 


call remove_(accept_procref, ,node/dbo/mg- process") 
call insert_ opt node. tabyerer) hr econ neo mnoceesr "first", 
accept_node_tableref 
/* “Receive” the messag 
rev_msg_numb = extract, A Oe waaacere: number_revd") + 1; 
call alter_(mgref, "message. number _| revd", rev mee ynumb) 
/* Get the name of the process that was awakened 
accept_) node_ name = extract accept_node_ tableref, 
"node table. name* 
accep vettee ra = extract_ accept_procref, "process. name"); 
eall ist_("Process", accept_proc_name, "at a ; 
ac cept node name, "has been awakened u one 
eall write_lis receipt of a message ac group", 
P_! ee 


/* Wake up “te process pointed to by naccept.. bed A #/ 


end; 
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q: 

OP_CON: procedure; 

/*“This procedure contains subroutines which create an operator connection, 
allow the operator to send messages over the connection, allow the 
operator to receive messages over the connection, and allow the 
operator to report its status (active or blocked} with respect to the 
operator connection. The following user visible fufictions are included: 

CREATE OPERATOR CONNECTION 
OPERATOR MESSAGE 


OPERATOR STATUS 
RECEIVE OPERATOR MESSAGE */ 
del con_opref fixed bin(17); 
del eos bit(1); 
del ndm_proc_ownerref fixed bin(17): 
del noderef fixed bin iy H 
del node_tableref fixed bin(17): 
del number_ad fixed bin: 
del obplref fixed bin u : 
del op_conref fixed bin(17); 
del opref fixed bin(17): 
del p_con_name char(#); 
del p_con_node_name char(#): 
del p_op_name ohar(*);: 
del p_op_node_name char(#); 
del p_process_name char(#): 
del process_name char 1233 
del proc_node_name ehar(12); 
del procref fixed bin(17); 
del ) state char(#); 
del ableref fixed bin(17); 
de write_list_ entry optionslvariable); 
finclude DDM_serv_ routines: 
Zinclude ADT_primitives: 
/* CREATE OPERATOR CONNECTION 7/9/76 #/ 


copeon: entry(p_con_name, p.con_node_name, P_Op_name, p_process_name); 
/* This procedure will create a connection between the operator apeoneaee 
by i ter oe and the process specified by "p_process_name", doth 
located at the node specified by "py _op_node_name". The connection will 
be given the name specified by "p_con_name"™ &/ 
/* atare ae epescene operator connection name, print an error message 
nd return 
if af ind entity loc(op sonnet "sys->op_con", SYS_REF, p_con_name, 
"op_con.name™ 
then do; 
eail write list_("Duplicate operator connection name.", 
% Weommand rejected"); 
return; 


end; 
/* If the node specified by "p_con_node_name" does not exist, print an 
error message and return *#/ 
if find_entity_loc(noderef, "sys->node", SYS_REF, p_con_node_name, 
"node.name" ) 
then do: 
eall write_list_("Invalid node name:", p_con_node_name, 
: Wdoes not exist"): 
return: 


end; 
/* Get the location of the node_table for "p_con_node_name" #/ 
eos = find_entity_loc(node_tableref, "node->node_table", noderef, 
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pcon node_nane, "node_table.name"): 
/* If the node is unaware of the existence of the operator, print an 
error message and return 
if find_entity_loc(opref, "node->operator", node_tableref, p_op_name, 
“operator. name® ) 
then do: 
call write list_("Invalid operator name:", p_op_name, 
Wdoes not exist at node", p_con_node_name); 
return; 


end; 
/* If the process specified by "p_process_name" does not exist at the 

node specified by "p_con_node_name", print an error message and return */ 
if find_entity_loc(procref , onoce— proses? node_tableref, 

- p-process_name, process.name" 
en do: 

eall write_list_("Invalid process name:", p_process_name, 

. Wdoes not exist at node", p_con_node_name); 
return; 


end; 
/* If the process specified by "p_process_name" is not active, print an 

error message and return */ 
call find_owner_(nd roc_ownerref, "node/dbo/mg->process", procref): 
if entity_class_name_ ndm_proc_ownerref) “= "node_table" 

en do; 

call write list_("Invalid copeon command. Process", p_process_name, 
Wis not active"); 
return; 


end; 

/* Create an entity for an operator connection and insert it into the 
propes sets */ 

cal create_entity (op conref, “op_con"); 

call create_attribute_Cop_conref, “op_con.name", "field" 12, Pp. son agne) 

call create_attribute_(op_conref, "op_con.number_qd", "rleld » 4, "6"); 

call create_relationship_(op_conref, "process=>0p_con", "member" ) ; 

call create_relationship_(op_conref, “operator->op_con", "member®); 

call create_relationship_(op_conref, "sys->op_con "member" ) ; 

eall create_relationship_(op_conref, "node/dbo/ -3process" owner"); 

call insert_(op_conref, process~>op_con® , "first" procref}; 

call insert_(op_conref, soperator->op_con » "first", gprer); 

eall insert op_conrer, *sya->op_con i "first", SYS_REF); 

char write_list_("Operator connection", p_con_name, "has been established"); 

return; 
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/* OPERATOR MESSAGE 7/13/76 %/ 
opmes: entry(p_con_name) ; 


were waiting for state information about the operator with respect to 
this operator connection will be discarded since the operator is active */ 


return: 
end; 
/* Discard any OBPL's that were waiting for state information from the 
operator that sent the message */ 
call Pind guner) opres poperetor-70p- Cons: op_conref); 
call find first_(obplref, "operator->obpl", opref, eos); 
do while (eos); 
call remove_(obplref, “operator->obpl"); 
calt find_first_(obpiref, "operator->dobpl", opref, eos); 
end: 
/* If no process is hy for the message, queve it an return */ 
if empty_ Spooner. "node dbo/mg->process" } 
en do: 
number_qd = extract_(op_conref, "op_con.number_qd") + 1; 
call alter_(op_conref, "op_con.number_qd", number_ad); 
call write_list_("No proces) is waiting for the message,", 
. ¥so it is queued"); 
return; 


end; 

/* A process is waiting for the message, so we must wake it up */ 

call find_first_(procref, "node/dbo/mg->proe ss", op_conref, eos); 

call remove_(procref, “node/dbo/mg->process"); 

call find_owner_(tableref, "node-Sprocess", procref) ; 

call insert_(procref, "node/dbo/mg->process", "first", tableref); 

/* Get the name of the process that was awakened *®/ 

process_name = extract_(procref, "process.name"); 

proc_node_name = extract_(tableref, "node_table.name"); 

call write list_(process_name, "at node", proe_node_name, "has been", 

awakened upon"); 

call write_list_(" receipt of a message over operator connection", 
A p_con_name) ; 

return: 
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/* or Oren TOR Sr AtUs eae 7/14/76 ma) 

opstat: entry(p_op_node_name, p_op_name, p_state, p_con_name);: 

7* This procedure will take the pg ed ep action when an operator 
reports that it is “active” or "waiting® #/ 

/* If the node specified by "p_op_node_name" does not exist, print an 
error message and return *%/— 

if find_entity_loc(noderef, "sys->node", SYS_REF, p_op_node_name, 

“node.name" ) 


then do: 
eall write list_("Invalid node name:", p_op_node_name, 
does not exist"); 
corns 
end; 
/* Get the location of the node table for the node specified by 
Mp ode_name" # 


op_n 

eos = find entity loc(tableref, "node->node_table", noderef, 
p_op_node_name, "node_table.name"); | 

/* if the operator specified by "p_op_name" does not exist at the given 

node, print an error message and return * 

if find’ entity_loctopref, "node->operator", tableref, p_op_name, 

“operator. name" ) 
then do: 
eall write list_("Invalid operator name:", p_op_name, 
i does not exist"); 

return; 


end; 
/* If the operator is active, we can discard all OBPL's that desired this 
state in ormation, and then return *# 
if p_state = "active 


then do; 
call find_first_(obplref, "operator->obpl", opref, eos); 
do while (“eos); 


call remove _(obplref, "“operator->obpl"); 
eall Find first (oppirer? Moperator->obp1", opref, eos): 


end: 

call write_list_("All OBPL's waiting for the given state", 
‘: Winformation have been discarded"); 

return: 


end; 
if p_state “= "waiting" 
then do; 
cail write list_("Invalid state. An operator can only be", 
‘ active or waiting"); 
return: 


end; 

/* If the operator connection specified by "p_con_name" does not exist, 
print an error message and return because one can not wait for a 
message over a non_existent operator connection */ 

if find_entity 1oc(op_genref, "sys->op_con", SYS_REF, p_con_name, 

*op_con.name* 
then do; 
call write_list_("Invalid operator connection name:", 
. p_con_name, "does not exist"); 
return: 


end: 

/* If the operator specified by "p_op_ name" is not involved with the 
oper ecen connection specified by "p_con_name", print an error message 
and return 

eall find, owner_(con,opref, "“operator->op_con", op_conref); 

if epree i econ_opre 

en do; 
cail write list_(p_op_name, "at node", p.op_node_name 
is not associated with operator connection", 
p_con_name); 
return; 
end; 
call write_list_("We will now check for deadlock involving the given", 
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"operator"); 

call write_list_(" and operator connection"); 

/* If the process that can send messages over the operator connection 
specified by ae con-name" is active, ‘there is ne deadlock, so 
discard ail 0 's that requested the given state information #/ 

call find_owner_(procref, "process->op_con", op_conref); 

call find_owner_(ndm_pro¢_ownerref, "ni /abo/mg=>process", procref): 

if entity c.ses aes. ndm_proc_ownerref) = "node_table" 

en do: 


eall find_first_(obplref, "“operator->obpl", opref, eos); 

do while ( gos); ao pee eat 
call remove _(obpjre operator->0 : 
ont Ping Pinot’ (ospire?” heute ta ED opref, eos); 
end; 

return; 


end; 
/* If there are no OBPL's waiting for state information about this 
operator, create an OBPL with the operater as the only process entry *#/ 
if empty peret, "operator->obp1") Fook 
en do; 


eail del_obpi(obplref p_op_nede, ame, ®", "op msg"); 
call del_pro _entry (obp ref, p_opnode_nane, P op_name); 
call insert_(obplref, "operator-dobpl", "first®, opref); 


end: ae ; 

/* Find out the name of the process that can send the message the 
operator desires */ 

process_name = extract_(procref, "process.name") 

/* expand eagh OBPL that required state information about the given 
operator Cha ane 

eall find first_(obpiref, "“operator->obpl", opref, eos); 

do while C"eos); 

/* Remove the OBPL from the set belonging to the given operator */ 

call remove_(obplref, “operator->obpi"}; 

fo cpeek it occ sete . eatcokS-/ ae ) 

call check_for_deadlock(obplref, pop-siode mame, process_name, eos); 

/* If eos = 1, then a deadlock was noe detect * so we should add a 
resource to the OBPL and then expand it ®/— 

if eos aa 

then do; Ry et At 
call obpi edd Fescurce oppteet ndm_proc_ownerref, 
p_op_node_name, eos)} 

/* If eos = 1 then the resource the process is waiting for 
is in the same node as the process, so we can continue 
to expand the OBPL *#/ ; 

if eos 

then call exp_obpl(obplref, p_op_node_name); 


end; 
/* See if there are any more OBPL's to be examined */ 
cet find_first_(obplref, “operator->odpl*, opref, eos); 
end; i 
return; a 
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/*# RECEIVE OPERATOR MESSAGE 7/13/76 */ 
revopmsg: entry(p_con_name); 
/* This Procoauce will simulate the receiving of a message by a process 
over the operator connection specified by "py con_name" &/ 
/* If the operator connection specified by 
print an error message and return */ 
if Find_entity_loc(op_genrer, "sys->op_con", SYS REF, p_con_name, 
“op_con.name" 
then do; 
call write list_("Invalid operator connection name:", p_con_name, 
does not exist"): 


p_con_name" does not exist, 


return; 


end; 
/* Get the name and node of the process that should receive the message */ 
call find_owner_(procref, "process->op_con", op_conref); 
process_name = extract_(procref, "process.name"); 
call find_owner_(tableref, "node->process" procref); 
proc_node_name = extract_(tableref, "node_table.name*); 
/* If the process is not active, eek an error message and return */ 
call find_owmer__(ndm_prod ownerre , "node/dbo/mg->process", procref); 
if ent tt ycl aaa name ndm_proc_ownerref) “= "node_table" 
en do; 
eail write_list_("Process" , 
proc_node_name, "is not active. No message can be"); 
call write_list_(" received over operator connection", 
p_con_name); 


process_name, "at node", 


return: 


end; 
/® Find out_if the message can be received, or if the process must be 
blocked #/ 
number_qd = extract_(op_conref, "op_con.number_qd"); 
if number_gqd >0 
then do; 
/* Remove one message from the queue */ 
number_qd = number_qd - 1; 
call alter_(op_conref, "op_con.number_qd", number_qd); 
call write_list_(process_name, "at node", proc_node_name, 
has received a message"); 
call write_list_(" over operator connection", p_con_name); 
return; 
end; 
else do: 
/*® Block the process and initiate processing of an OBPL */ 
call remove_(procref, "node/dbo/mg->process" ): 
call insert_ Denes! "node/dbo/mg->process", "first", 
op_conref):;: 
eall write List_(*"Process", process name, "at node® , 
proc_node_name, “is blocked waiting for a"); 
call write_list_(" message over operator connection", 


p_con name : 

call initiate_o pi (prog_node_name, process_name, proc_node_name, 
A p_con_name, "op_msg"); 

return; 


e 
end OP_CON: 


? 
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RCV_CM: procedure: 
/* This procedure is a collection of subroutines which will accept 
a control message and take the appropriate action. The following user 
visible funotion is included: 
Site eae Meee eee cout inca ge imanides 
e follow su reutines are inclu : 
PROCESS SSAGE 


MESSAG 
PROCESS OBPL PASS 
PROCESS “PROCESS TERMINATION" 
PROCESS RESOURCE GRANT 
PROCESS RESOURCE RELEASE 
PROCESS RESOURCE REQUEST #/ 


del accept_node_name char(12); 

del accept_node_tableref fixed Bin(I7); 
del accept_proc_name ehar(12); 

del accept_procref fixes bin(17): 
del access_type ehar(9): 

del cont_msg_numb fixed bin; 

del cont_msgref fixed binl17): 
del cont_msg_type ehar(20); 

del ) name ehar(12); 

del dbo_node_nanme ehar(12); 

del dbo_noderef fixed bin(17); 
del dboref fixed bin(17); 
del dbo_tableref fixed bin(17); 
del eos bit PF 

del mg_name char(12); 

del meref fixed bin(17); 
del n mee onceenennel fixed bin(17); 
del obpiref ek in(17); 
del p_cont_msg_numb char(§): 

del p_msgref fixed bin(17 ; 
del p_obpl_passref fixed bin(17): 
del p_res_grantref fixed bin(17): 
del p_res_relref fixed bin( 17): 
del p_res_reqref fixed bin(17); 
del process_name oparhls f 

del proc_node_name char(12): 

del proc_noderef fixed bin(17); 
del procref fixed bin(17); 
del proc_tableref fixed bin(17); 
del qd_msg_numb fixed bin; 

del rev_msg_numb fixed bin: 

del rev_node_name ehar(12): 

del sh_asmtref fixed bin(17); 
del write _list_ entry options(variable); 
Zinclude DDM_serv_routines; 

Zinclude ADT_primitives: 

/* RECEIVE CONTROL MESSAGE 6/15/76 #/ 


receive_control_message: revem: entry(p_cont_msg_numb); 

/* This procedure will verify that the control message which has its number 
al eS ba by "p_cont_msg_numb" has been sent, but has not been received. 
The procedure will then determine what type of control message it is, and 
the appropriate subroutine will be called to act on the message. */ 

call find_first_(cont_msgref, "sys->control_message", SYS_REF, eos); 

/* roeere the control message number from a character string to a numeric 
value 

cont_msg numb = p_cont_msg_numb: 
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/* Find the control message with number specified by "p_cont_msg_numb" */ 
do while (“eos); 
if extract__(cont_msgref, "control_message.number") = cont_msg_numb 
en do: 
/* Remove the control message from the set of control messages 
eae y this control message will not be received a second 
C) 
call remove_(cont_msgref, "sys->control_message"); 
/* Find out what type of ‘control message it is, and call the 
routine that will take the appropriate action * 
cont_msg_type = entity_class_name_(cont_msgref); 
if cont_msg type = "msg" 


then do 
call write_list_("Control message_number", 
P cont_msg_numb, a a message", 


In a message group"); 
call write list_(* nes been received"); 
call process_msg(cont_msgref); 
return; 


end; 
if cont_msg_type = "obpl_pass" 
then do; 

eall write_list_("Control message number", 
R cont_msg_numb, Fe) casa an OBPL", 
has been received."); 

call process_obpl_pass(cont_msgref); 

return; 


end; 
if cont_msg_type = "res_grant" 
then do; 
eail write_list_("Control message number", 
p_cont_msg_numb, iepresenting a remote", 
resource allocation"); 


call write_list_(" has been received"): 
sett process_res_grant(cont_msgref); 
return: 


if t. ee Md 1" 
cont_ms e = "res_re 
then des” 
call write_list_("Control message number", 
p_cont_msg_numb, "representing a remote", 
resource release"): 


call write _list_(" has been received"); 
call process_res_rel(cont_msgref): 

pies 

end; 


if cont_ms type = "res req" 
then a6: 


oO 

call write_list_("Control message number", 
p-cont_msg_numb, "representing a remote", 

resource request"); 


eall write_list_(" has been received"); 
call process_res_req(cont_msgref); 

penuen: 

end: 


end; 
call find_next_(cont_msgref, "sys->control_message", eos): 


end; 

/* If Rd one eee _numb™ didn't match ae control message number, then we 
should print an error message and return *#/ 

eall write_list_(p cont meg nye, " is not a valid control message number.", 
: ® Command rejected"); 

return: 
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/* PROCESS Sy ogee 7/1/76 */ 
process msg: entry( Py magref): 
* This roooscure will receive a pare y ie in a message eroees a@ process 
is waiting for this message, it will be woken up, otherwise Ske message 
will be "queued" 
/7* Get the name and iocabion oe ee Se nena group */ 
me_name = extract_(p_! megref, oma 
eos = find entity_ oil sed ‘ "syo->nessage”: SYS REF, mg_name, 
message .name 
/* acknowledge receipt of the message by adding 1 to the number of messages 
that have been queued in this message group * 
qd_msg_numb = extract_(mgref, seeaeege: -number qd") + 1; 
call alter _(mgref "message. number _ numb); 
/* Jf no proc s has accepted the = group, return */ 
if ager ed__ marer, “pev_proc->message 
en do; 
call write, list_("Message group", mg name, “ae not been", 
; Wacecepted. The message is queued." 
return: 


end; 
/* Get the name and node of the process that can receive the mocneee #/ 
call find_owner a eutracte ref, "rev_proc->message", mere 
accept_proc_name = extract. qa nocept _proorer, rocess.name"); . 
eall find_owner_ Concept pads e_tableref TN ape Q->mess sa, mgref); 
accept_node_name = e ct_(accept_node_tableref, "node_table.nane"); 
/* Keep the message queued if the process is not waiting for it. Otherwise 

wakeup the process. 
call find_owner nda proc ownerref, "node/dbo/mg->process", accept_procref) ; 
if ndm_proc_ownerref mgre 
then call write list. ("No epi coese is waiting for the message,", 
feerd "so if is queued 
else do; 

eall remove_(acecept_procref, "node/dbo/mg->process® ): 
call insert_ eptnode, tabier ho es "first", 

mace node_tableref i 
rere msg shag 2 = extract _( mgref, “message.number_rcvd") + 1; 
call att. meref, "message. number. reva", eee oy tat pod 
eall unite: ii st. nt Process ", wpocept_pr 

Becept_ pode. name, “has been aw u on” 

eall write_list_ receipt of a skened | n message group", 

me_name): 


£ pode le 


end: 
return: 


/*# PROCESS OBPL PASS 6/24/76 &/ 

process_ obpl_pass: entry(p_obpl_passref); 

/* This procedure will allow a partially expanded OBPL to be "received" by a 
node and then be expanded as much as possible within that node */ 

/* Get the location of the OBPL entity that has been "passed" between nodes. 
We need not check "eos" because we know the desired entity exists. * 

call find_first —(obpiref, e-redeiving the, curd paseret, eos); 

/* Get the name of the node receiving the control message. 

rev_node_name = extract —(p,ob z-parerer "obpl_pass. fee foaa. name"); 

/* Remove the OBPL from this Gon rol message so that we can send the’ expanded 
OBPL in another control message if foo 

call remove_(obplref, "ob "abeposaible 1 ; 

/* Expand the OBPL as much as possible in the receiving node */ 

ha exp_obpl(obplref, rev_node_name) 

return: 
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/* PROCESS RESOURCE GRANT 6/15/76 */ 

process_res_grant: entry(p_res_grantref); 

/7* This procesure will wake up a process and give it access to a resource as 
specified by the remote resource grant control message pointed to by 
"p res_grantref* #/ 

/* Get the names of the process, resource and nodes involved */ 

process_name = extract_(p_res_grantref, "Pee_grant . proc_nasme’); 

proc_node_name = extract_(p_res_grantref, "res_grant.proc_node_name"); 
dbo_name = extract, pper_srantret, npea_grant.red nase"); 

dbo_node_name = extract, P res_grantref, "res_grant.res_node_name"); 

/* Find the locations of the entities for the process, resource and their node 
tables within the node specified by "proc_node_name". Note that we need 
not test “eos" because we know the names placed in the control message 
represent existing entities. */ 

eos = find_entity_loc(proc_noderef, "sys->node", SYS_REF, proc_node_name, 


node .name"); 
eos = find_entity_loc(proc_tableref, "node->node_table", proc_noderef, 
proc node_nane, Wnode_table.name"); 
eos = find ent ty_loe Payers "node->process", proc_tableref, process_name, 


process.name"); 
eos = Saisie Noga loc(dbo_tableref, "node->node_table", proc_noderef, 


no le name node_table.name"): 
eos = find_entity_loe(dboref, "node->dbo", dbo_tableref, dbo_name, 
Fdbo. name"): 


/* Unblock the process #/ 
call remove_(procref, "node/dbo/mg->process"); 
call insert_(procref, "node/dbo/mg->process", "first", proc_tableref): 
/* Give the process exclusive or shared access to the dbo, depending upon the 
type of access that was requested. 
if extract_(prooref, "process.access_ type") = "exclusive" 
en do; ; 
/* Grant the process exclusive control of the database object */ 
call insert_(dboref, "process->dbo", "first", procref); 
call write _list_(process_name, "at node", proc_node_name, 


has been granted exclusive use of"); 
call write_list_(" ", dbo_name, "at node", dbo_node_name); 
return; 
end; 
else 


do; 
/* Grant the process shared access to the database object #/ 
call del_dbo_sh_asmt(sh_asmtref); 
call insert_(sh_asmtref, "dbo->dbo_sh_asmt", "first", dboref); 
call insert_(sh_asmtref, "process->dbo_sh_asmt", "first", procref); 
call write list_(process_name, "at node", proc_node_name, 

has been granted shared access 0"); 
call write_list_(" t, dbo_name, "at node", dbo_node_name); 
Ped ata 
end; 
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/* PROCESS bis es RELEASE 6/15/76 */ 

process_res_ rel: entry ( p_res_relref); 

/* _ procedure will release a resource from control by a remote process, 

speck t sec in the resource release centrol message. If possible, 
addi ional processes will be removed from the queve for 8, database 

object and will be granted access to the database 6 object 

/* Get the names of the process, resource and nodes involved oy, 

process_name = extract LfP. esrelrel "rea_rel, ne c_name™); 

proc_node_name = e a,reiref, _name"); 

dbo_name = extreet rs »."res_rel.. ast_A ) name") ; 

dbo_node_name = extract_. Pat Oraaee lref, * babe Panes) name"); 


/* Find the iscat ines oF ihe entities for the: eeass, resource and their 
node tables within 1 nade epeni tied by * ", Note that we 
do not test “eos M comune we Dames p, in the resource release 


control message sent existing entities. 
eos = Find entity loe'| sbo_! noderef, "sys->node", dys. REF, dbo_node_name, 
name" 
eos = fin entity loe! dbo tableref "node~>node » table", dbo_noderef, 
ey Toets Wy table.name* 
findyentity Te e(aboref, Wnode->dbo*, dbo y tableref, dbo_name, 


eos = find entity yatoel proc Meee Cepia oer "node~>node. . table", dbo_noderef, 
e.name" 


core ode name » *¥node_ta 
eos = find ent ty_loc(procref, "node-3 recess", proe_tableref, 
name, "process. 

call write “list {abo néme, Wat node", “dbo_node_name name, "has been released by"); 
call write_list process_! name, node", proc node_name 
/* Check if the | process had exclusive pork Eo of the database object */ 
if insert (dberef, "process->dbo 

Se. 

/* Release the database object and then grant at least one other 

proores access to the database object if any processes are 
ueued for 
cal} remove Sorted “process->dbo") ; 


eos 


if “em node/dbo/mg~>process" ) 
thes oall F rem_proc_ from_queus(d dboref, dbo_tableref); 
return; 
end; 
else do: 


/* Release the database object from this shared assignment, and if 
there are no other processes currently having shared access to 
the database object we can grant another process access to the 
database object if any are queued for it 

call find_first_intersection_(sh_asmtref pbroceee, 7 7Par en Aaee 

procref, "dbo->dbo_sh Tee ane ndbore eos); 

call delete_entity_(s asatref ome}; 

if member count (dboref, Ndbo-ddbe 8 saat”) z 0 

then i empty_ (abaret. "node dbo/ve- ->process 
chen eal rem_proc_. from _queue(dboref, dbo  eablerer); 
ener 

end; 
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/* PROCESS RESOURCE REQUEST 6/15/76 */ 

process_res_req: entry(p_res_reqref); 

/* This procedure will process a request for a resource from a remote 
process: as specified in the resource request control message. If 

he resource can be assigned, it will be and a control message will 
be generated to that effect. Otherwise the process will remain blocked 
until the resource becomes available. * 

/* Get the names of the process, resource and nodes involved */ 

process_name = extract_(p res_reqref, "res_req.req_proc name") ; 

proc_node_name = extract_(p_res_reqref, "res_req.req_node_name"); 

dbo_name = extract, (pres reqref, res_req.dest_dbo_name"); 

dbo_node_name = extract P res_reqref, "res_req.dest_node_name"); 

/* Find the locations of the entities for the process, resource and their 
respective node tables within the node epee fied by "dbo _node_name". If 
the node is unaware of the existence of the process, create a local entity 
for that process. e do not have to test eos because we know the entities 
for the node tables and the resource exist because the names were placed 
in the resource request control message 

eos = find entity_loc dbo_noderef, "sys-dnode", SYS_REF, dbo_node_name, 


node.name" ); 
eos = find_entity_loc dbo_tableref "node->node_table", dbo_noderef, 
) node_name, "node_table.name"); 
eos = find,entity loe(dborer, "node->dbo", dbo_tableref, dbo_name, 
-name"); 
eos = find_entity. loel proe tableref, "node->node_table", dbo_noderef, 
proc_no e_name, "node_table.name"); 
if find_entity_loc(procref, "node->process", proc_tableref, process_name, 
"process.name" 
then do; 
/* Create a "local" entity for the process, since one does not 
already exist */ 
call del_process(procref, process_name) ; 
call dj apert—|brceres) gnome? pogee ee: first", proc_tableref); 
call insert_(procref, "node/dbo/mg->process", "first", 
a proc_tableref): 
end: 
/* Determine what type of access is desired */ 
agcess_type = extract_(p_res_reqref, "res_reg.sccess type"): 
/*® Check if the database object might be available for assignment */ 
if inserted_(dboref, "process->dbo") | empty _(dboref, "node/dbo/mg->process" ) 
then do: /*Block the process if the database object has been 
eect anes to another process for exclusive use or 
if other processes are currently queued for the 
database object 
call alter_(procref "process.access_type", access _type);: 
eall renove_{procret, node/dbo/mg->process"); 
eall insert_(procref, "node/dbo/mg->process", "last", dboref): 
call write_Iist_("Resource not available, process remains blocked"); 
eall initiate_obpl(proc_node_name, process_name, dbo_node_name, 
i dbo_name, "dbo"): 
return; 


end: 
/* Check if the request is for shared access */ 
if access_type = "shared 
then do; /*Give the process shared access to the desired 
database object #/ 
eall del_dbo_sh_asmt(sh_asmtref); 
call insert_(sh_asmtref, "dbo->dbo_sh_asmt", "first", dboref); 
call insert_(sh_asmtref, "process->dbo_sh_asmt", "first", procref): 
call write _list_(process_name, "at node", proc_node_name, 
Wis granted shared access to"): 
call write_list_(" ", dbo_name, “at node", dbo_node_name): 
call del_rem_res_grant(dbo_node_name, dbo_name, proc_node_name, 
process_name, cont_msa@_numb): 
call write list_("Control message number" , cont_msg numb , 
Wsent from", dbo_node_name, "to", proc_node_name); 
call write_list_(" represent ing this allocation"): 
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return: 


end; 
/*The next if statement will be executed if the request is for 
exclusive use of the database object *# 
/* Check if any process has shared access to the desired database object */ 
if “ empty_(dboref, "dbo->dbo_sh_asmt") 
then do: /*Queue the process for exclusive use of the database 
object because at least one other process currently 
has shared access to the database object. 
call alter_(procref "process.access_type", "exclusive"); 
call renove_{procret, node/dbo/mg->process"); 
call insert_(procref, "node/dbo/mg->process", “last", dboref); 
call write List_("Resource is not currently available for", 
exclusive use, process", process_name); 
call write_list_(" at node", proc_node_name, 
Wremains blocked"); 
eall init tate obi s Proc node-name, process_name, dbo_node_name, 


bo_name, 
return: 
end; 
else do; /*Grant the paceee® exclusive use of the desired 
database object. %/ 


call insert_(dboref, "process->dbo", "first", procref); 
call write_list_(process_name, "at node*®, proc_node_name, 

is granted exclusive use of"): 
call write_list_(" ", dbo_name, "at node", dbo_node_name): 
call del_rem_res_grant(dbo_nede_name, dbo_name, proc_node_name, 

process name, cont_msg_numb): 

call write_list_("Control message number", cont_msg_numb, 

sent from", dbo_node_name, "to", proc_node_name) ; 
call write_list_(" representing this allocation"); 
return: 
en 

end RCV_CM; 


. 
* 
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4%: 
OBPL: procedure; 


This procedure is a collection of subroutines which act on 


an OBPL and check for deadlock. 


The ro atte CR FBR DEAD routines are included: 


R DEADLOCK 


EXPAND PBBPL 
OBPL ADD RESOURCE 


del eos 
del first_procref 
del message_numb 
del . ref 
del ndm_proc_ownerref 
del new_obplref 
del obpl_proc_name 
del obpl_proc_node_name 
del obpl_proc_node_tableref 
del obbl procref 
del old_proc_entryref 
del op_conre 
del operator_name 
del opref 
del eet Aas 
del 
del Ls nee roc_ownerref 
del p_obplref 
del p-process name 
del p_proc_node_name 
del p_rev_node_name 
del proc_entryref 
del process_name 
del proc_node_name 
del procref 
del proc_tableref 
del rev_noderef 
del res_name 
del res_node_name 
del res_node_tableref 
del resref 
del res— type 
del ref 

del wr te_list_ 


qenalude DDM_serv_routines: 
Zinclude ADT_primitives; 
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bit(1):; 
fixed bin(17): 


fixed bin(17): 
char 12); 
fixed pint} : 
enact bin(1 
char(7 


fixed aac 17) 
entry options( variable); 


Procedure OBPL 


Appendix II Procedure OBPL 


/* CHECK FOR DEADLOCK 6/25/76 #/ 
check_for_deadlock: entry(p_obplref, p_proc_node_name, p_process_name, Pp eos): 
/* This procedure will check if the process specified by P_process name 
and located in the node specified by "p_proc_node_name" already has an 
entry in the OBPL pointed to by "p_obplref". If no such entry exists 
then one will be created and "p_eos" will be set to "1"b, indicating that 
there is no deadlock. If an entr arreecy exists for the process, we 
have a deadlock and a message will be printed giving the processes 
involved and "p_eos" will be set to "0"b indicating a deadlock has been 
detected. */ 
/* Get the tree ioe of the first proc_entry in the OBPL */ 


eall find_first_(proc_entryref, "“obpl->proec_entry" pooppirer p_eos); 
/* For each proc_entry in the OBPL, check if it mate es the given process: 
Note that if we detect a deadlock, we will return from inside the loop 


and p_eos will be 0. If no deadlock is detected we will exit the loop 
before returning and p_eos will be 1, as desired. 
do while (“p_eos): 
/* If we have a match with "p_process_name" and a proc_entry, we must 
then check if the node name attribute matches "B-prog Node name #/ 
if p_process name = extract_(proc_entryref, "proc_entry.process_name") 
hen if P_proc_node_name = extract_(proc_entryref, 
proc_entry.node_name" ) 
then do; 
/* A deadlock has been detected, list all the processes 
involved and return. #* 
call write_list_("A deadlock has been detected." , 
*The following processes are involved:*); 
eos = "0"b; 
do while (“eos): 
process name = gp ease gp bat 
"prog entry. process_name") ; 
proc_node_name = extract_(proc_entryref, 
*proc_outry..node_nsme"); 
call write _list_(" ", process_name, 
at node ", proc_node_name); 
call find prior_(prec_entryrsr, "obpl->proc_entry", 
eos); 


end: 
call write_list_(" End of deadlock list"): 
return: 
end; 
/* Get the next proc_entry in the OBPL %/ 
call find_next_(proc_entryref, "obpl->proc_entry", p_eos): 


end: 
/* No deadlock has been detected, so create a new proc_entry and have it 
inserted into the OBPL #/ 


Shae del_proc_entry(p_obplref, p_proc_node_name, p_process_name): 
return: 
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/* er Corr ores < nes 6/25/76 */ 

copy_obpl: en p_copyref, p_obplref): 

/* This procedure will copy the OBPL pointed to by mp_obplrer and return 
a pointer to the copy via "p_copyref". The order of the OBPL entries, 
and their attribute values in the copy will be identical to those in 
the original. #/ 

/* Get the attribute values (resource information) from the OBPL entity 
pointed to by "p_obplref". #/ 

res_name = extract_(p_obplref, pope) Fea namer): 

res_node_name = extract_(p_obplref, "obpl.res Rode_nanet); 

res_type = extract_(p obpiref, nObp1.res_typer ; 

/* Create an OBPL entity with the above attribute values */ 

call del_obp1(p_copyref, res_node_name, res_name, res_type); 

message_numb = extract_{p obplref, "obpl .ms&_numb");: 

call alter_(p_copyref, “obpl.msg_numb" message umd): 

/® Get the last entry in the OBPL pointed to by npaopehyer #/ 

call find_last (old_proc entryref, "“obpl->proc_entry", p_obplref, eos): 

/* Copy eagh OBPL entry */ 

do while (eos): 

/* Get the attribute values of the proc_entry pointed to by 
"old_proc_entryref" #/ 

process_name = ract_(old proc_entryref, "proc_entry.process_name"); 

proc_node_name = extract_(old_proc_entryref nproc_en ry .node_name"): 

/* Create a new proc_entry with the above attribute values an 
insert it into the new copy of the OBPL. */ 

¢all de roc_entry(p_copyref, proc_node_name, process_name); 

/* See if there are any more proc_entries to be copies #/ 

gait find_prior_(old_proc_entryref, "obpl->proc_entry", eos); 

end: 

return: 
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7* EXPAND OBPL 6/24/76 */ 

exp_obpl: entry(p_obplref, p_rcv_node_name): 

/* This procedure will expand the OBPL pointed to by "p_obplref". It will 
be expanded as much as poxxible using the information available to the 
node specified by ippegv node name" 

/* Get the fully qualified name (resource name plus the name of the node 
in which it resides) of the resource which is controlled by or being 
waited for by the last process to be added to the OBPL. (Note that we 
add processes to the OBPL by inserting them at the beginning of the set */ 

res_name = extract_(p_obplref, coups cen amen); 

res node_name = extract_(p_obplref, "obpl.res_node_name"); 

/* Get the type of the resource ("message" or "dbo™ or "op_msg") #/ 

res_type = extract_(p_obplref, "obpl.res_type"); 

if res_type = "message" 

then do: 

/* The resource type is a message, therefore we know the process 
that can send e desired La tarps is in the node that is 
expanding the OBPL. We will act accordingly. 

/* Get the location of the entity for the message group from which 
a message is desired. We need not test "eos" because we know 
the entity exists. *# 

eos = find entity_loc(mgref, "sys->message", SYS REF, res_name, 

message .name");: 

/* Get the number (within the message group) of the message 
that is desired. *#/ 

message_numb = extract_(p_obplref, "ob 1, mog_numb"); 

/* If this number is less than or equal to the number of messages 
gent in this message group, then there is no deadlock. */ 

if ~ (message_numb > extract_(mgref, "message .number_sent") ) 

then return; 

/* Find the process that can send the desired message */ 

call find_owner_(procref, "send _proc->message", mgref); 

/* Find out if the process is active. If it Is active there 
is no deadloc / 

eall find_owner_ 

procref): 

if entity_class_name_(ndm_proc_ownerref) = "node_table" 

then return; 

/* Get the process name and check for deadlock */ 

process_name = extract_(procref, "process.name"); 

call check_for_deadlock(p_obplref, res_node_name, process_name, 


Cadac a noe ounarner: *node/dbo/mg->process", 


eos); 
/* If eos = 0 then a deadlock has been detected and we are done */ 
if (“eos) 
then return: 
/* add the resource that the process is waiting for to the OBPL #/ 
call obpl_add_resource(p_obplref, ndm_proc_ownerref, 
p_rev_node_name, eos): 
/* If eos = 1 then the resource the process is waiting for is in 
the same node as the process, so we can continue to expand 
the OBPL. #/ 
f eos 
then call exp_obpl(p_obplref, p_rev_node_name);: 
return: 
end; 
if res_type = "op_msg" 
fhen do: 


/* The resource type is an operator message, therefore we know 
the last process to be added to the OBPL is waiti for a 
message from an operator at the same node. We will act 
accor i page 

/* Get the location of the entity for the operator connection 
over which a message is desired */ 

eos = find_entity_loc(op_conref, "sys->op_con", SYS_REF, 

res_name, "op _con.name"); 

/* Get the location and name of the operator who can send the 
desired message */ 
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call pind owner \oprer “operator=->op_con", op_conref); 
operator_name = ex ract_(opref, "operator.name"): 
/* Check if the operator is already in the OBPL list */ 
call check_for_deadlock(p_obplref, res_node_name, 
operator_name, eos); 
ie a = = 0 then a deadlock has been detected and we are done */ 
eos 
then return: 
/* Queue the OBPL and request status information from the 
operator */ 
call insert_(p obpiref 7 opaneser 7 cope. "first", opref); 
call write_list_("An OBPL has been queued waiting for a status", 
report from operator", operator_name) ; 
call write _list_(" at node", res_node_name, 
: *The Involved operator connection is", res_name): 
return: 


end; 
/* If the next section is executed, a database object is controlled by or 
is being waited for by the last process to be added to the OBPL */ 
/* Get the name and location of the last process to be added to the OBPL */ 
call find_first_ obpi_proeref “obpl->proec_entry", p_obplref, eos); 
obpl_proc_name = extract_(ob 1 procref, “proc_entry.process_name" ; 
obpl_proc_node_name = extract_Cobpl_procref, "proc_entry.node_name") ; 
/* Get the entity locations for the database o acre and its node table, and 
the process and its node table within the node specified by 
"p rev_node_name™. We need not test "eos" in most cases because we 
know the entities exist *# 
eos = find entity_loc rev_noderef, "sys->node", SYS_REF, p_rev_node_name, 
node .name"); 
eos = find_entity_loc ober proc_node_tableref, "node->node_table", 
rev_noderef, obp roc_node_name, "node_table.name"); 
find_entity_loclres node_tableref, "node->node_table", rev_noderef, 


eos = 
res_node name node_table.name"); 

eos = find_entity_loc obpl_procref, "node->process", obpl_proc_node_tableref, 
obpl_proc_name, "process.name"); 


/* We must test "eos" to see if the node containing the resource is aware 
of the existence of the most ponent ry inserted process in the OBPL. If 
ie it is not, we have no deadlock at this time, so we can return 
eos 
then return: 
eos = find_entity_loc(resref, "node->dbo", res_node_tableref, 
res_name, "dbo.name"); 
/* Check if the resource is in the node that is expanding the OBPL */ 
if res_node_name = p_rcv_node_name 
then do; 

/* Verify that the process specified by "obpl_proc_name" is still 
waiting for the resource specified by "res_name*® #/ 

call find_owner_(nd roc_ownerref, "node/dbo/mg->process", 

obpl_procref) ; 

if resref = ndm_proc_ownerref 

then return: 

/*® We must now add an entry to the OBPL for the process 
that controls the resource specified by "res_name", 
pees that the process is not already in the 

BPL. If there are n processes that have shared 
access to the database object, then we must create 
n copies of the OBPL and use a different copy 
for each reader 
if inserted_(resref, "process->dbo") 
then do: 
/* The database object is held for exclusive 
use. Find the controlling process and 
check for deadlock. * 
call find_owner_(prooref, "process->dbo", 
resref); 
process_name = eptract(procret, "process.name"): 
call find_owner_(proc_tableref, "node->process", 
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procref): 
proc_node_name = exreect=tproc-tableret, 
"node_table.name"): 
call find_owner_(ndm_proc_ownerref, 
"node/dbo mg >process” procref);: 
/* If the process is active and it is at the 
same node as the resource, then we have 
no deadlock. ® 
if entity_class_name (ndm_proc_ownerref) 
= "node_table" proc_node_name 
= res_node_name 
then return: 
call check_for_deadlock(p_obplref, 
proc_node_name, process yane, eos); 
/* If eos = 0, than a deadlock has been 
detected and we are done */ 
if (eos) 
then return; 
if proc_node_name = res_node_name 
then do; 

/* The process is in the same node as 
the database object, so we can 
continue to expand the OBPL */ 

/* Add to the OBPL the resource that the process 
is waiting for #/ 

call obpl_add_resource(p_obplref, 

ndma_proc_ownerref, 
p_rev_node_name, eos); 

/* If eos = 1, then Ehe resource that was added 
to the OBPL is in the same node as the 
process that is beet for it, so we can 
further expand the OBPL #/ 

if eos 

then call exp_obpl(p_obplref, 
p_revy_node_name): 

return: 

end: 


do: 

/* Send the OBPL to the node specified 
by nproc_node_name® */ 

call del_obpl_cont_msg(p_obplref, 


else 


proc_node_name, p_rcev_node_name); 
return; 
end: 


end; 

/* If the following code is executed, the database object 
has n readers. We need to make n-1 additional copies 
of the OBPL. Each time we make a copy of the OBPL, 
we expand that copy as much as possible for the given 
pore and the process that we are associating with 

s copy 

/* Find a process that has shared access to the 
database object *#/ 

call find_first_(sh_asmtref, "dbo->dbo_sh_asmt", 

resref, eos); 

eall find_owner_{first_procref, "process->dbo_sh_asmt", 

sh_asmtref); 

/* We will check for deadlock involving the OBPL and the 
process pointed to by "first_procref" after we check 
for deadlock with all the other readers of the 
database object. We will teherefore use the “original" 
OBPL (rather than a copy) for this check */ 

call find _next_(sh_asmtref, "dbo->dbo_sh_asmt", eos); 

do while ("eos): 

/* Find the process that has the shared access 
represented by the dbo_sh_asmt entity pointed 
to by "sh_asmtref" #/— 
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call find_owner_(procref, "process->dbo_sh_asmt", 

sh_asmtref): 

process name = extract_(procref, "process.name") ; 

/* Get the name of the node in which the process 
resides */ 

eall Find couner toroc-tablenet; "node->process", 

procref); 

proc_node_name = extract_(proc_tableref, 

"node_table.name"): 

/* If the process is not active or if it is at a node 
different from the node in which the resource 
resides, then we must check for deadlock. *#/ 

call find_owner_(ndm_proc_ownerref,, 

"node/dbo Bg RU Cceee procref); 
if entity_glass_name_ ndm_proc_ownerref) 
= "node_table" | (proc_node_name 
= res_node_name} 
then do; 
ee 2 ps ang chest for eis a/ 
call copy_obpl(new_obplref, p_obplref); 
call check_for_deadlock(new_obplref, 
proc_node_name, process_name, eos): 
/* If eos = 1 then we must either continue 
to expand the list or send it to 
another node */ 
if eos 
then if proc_node_name = res_node_name 


O5 

/* Add to the OBPL the resource that 
the process is waiting for * 

call obpl_add_resource( 

new_obplref, 
ndm_proc_ownerref, 
p_rev_node_name, eos); 

/* If eos = 1, then the resource that 
was added to the OBPL is in the 
same node as the process that is 
waiting for it, so we can further 
expand the OBPL #7 


if eos 
then call exp_obpl( 
new_obplref, 
p_rev_node_name): 


end; 
else cali del_obp]_cont_msg( 
new_obplref, 
proc_node_name, 
p_rev_node_name); 


end: 
/* See if there are any more readers of the database 
object specified by "res_name" 
call ind_next_(sh_asmtref, "dbo->dbo_sh_asmt", eos); 
end: 
/* Find the process name and the node in which it resides 
for the process pointed to by "first_procref" #/ 
process_name = ey eneee (first_procref, "process.name"); 
call find_owner_(proc_tableref, "node->process", 
first_procref): 
proc_node_name = extract_(proc_tableref, "node_table.name"): 
# If the process is at the same node as the resource and 
it is active, we need not check for deadlock. */ 
eall find_owner_(ndm_proc_ownerref, "node/dbo/mg->process", 
first_procref): 
if entity_class_name_(ndm_proc_ownerref) = "node_table" 
roc_node_name = res_node_name 
then return; 
/* Check for deadlock and then expand the OBPL or send 
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it to another node */ 
call check_for_deadlock(p_obplref, proc_node_name, 
if process name, eos): 

eo 


s 
then if proc_node_name = res_node_name 
then do; 
eail obpl_add_resource(p_obplref, 

Edn eroc_ownerret, p_rcv_node_name, 
eos); 

if eos 

then call exp_obpl(p_obplref, 
p_rev_node_name) ; 


end; 
else call dcl_obpl_cont_msg(p_obplref, 
proc_node_name, p_rcv_node_name): 
eecuen, 
end: 
/* The next section of code will be executed if the resource is_ located 
in a node different from the one that is expanding the list #/ 
/* First check if the process is active. If it is active, we are done */ 
call find_owner_(ndm_proc_ownerref, "node/dbo/mg->process", obpl_procref): 
if entity_class_name_(ndm_proc_ownerref) = "node_table" 
then return: 
/* Verify that the process specified by "obpl_proc_name" still controls 
the resource specified by "res_name" #/ 
/* See if the process had either exclusive or shared access to 
the database object specified by "res_name*, If it has neither, 
we can return. °/ 
if (empty_intersection_(obpl_procref, "process=>dbo", res_node_tableref, 
"node->dbo")) & eapty_intersecticn_(obpi_procret, 
ee pppocere 7 obec eit aest , resref, "dbo=->dbo_sh_asmt") ) 
en return; 
/* Add to the OBPL the resource that the process is waiting for */ 
call obpl_add_resource(p_obplref, ndm_proc_ownerref, p_rev_node_name, eos): 
/* If eos = 1, then the resource that was added to the OBPL is in the same 
henge ay process that is waiting for it, so we can further expand 
e 


if eos 
then call exp_obpl(p_obplref, p_rev_node_name); 
return: 
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/* OBPL ADD RESOURCE 6/24/76 #/ 
obpl_add_f esourse: entry(p_obplref, p_ndm_proc_ownerref, p_rev_node_name, 
p_eos); 


/* This procecure will be passed a pointer to a resource that the most 
recently inserted process in an OBPL is waiting for. The procedure will 
determine the type of resource that "p_ndm proc_ownerref" points to, and 
will insert information about this resource into the OBPL entity pointed 
to by "p_obplref". If the resource is in the node specified b 
"p_rev_node_name", then p_eos will be set to 1, otherwise it will be set 
to 0 and the OBPL will be sent to the node that contains the resource */ 

if entity_class_name_(p_ndm_proc_ownerref) = "dbo" 

en do; 
/* Get the database object name and get the name of the node in 
which it resides #/ 
res_name = extra t_(p_ndm_proc_ownerref "dbo.name"); 

eall find_owner_(res_node_tableref, "node->dbo", 

p_ndm_proc_ownerref); 

res_node_name = extract_(res_node_tableref, "node_table.name"); 

et alter_(p_obplref, "obpl-res_type", "dbo"); 


end; 
if entity_class_name_(p_ndm_proc_ownerref) = "message" 
en do; 
/* Get the message group name and the name of the node from 
which a message should be coming *®/ 
res name = extract_(p_ndm_proc_ownerref "message .name"); 
call find_owner_(res_node_tableref, ninit_node- message", 
p_ndm_proc_ownerref); 
res_node_name = extract_(res_node_tableref, "node_table.name"); 
/* Get the number of the message (within the message group) that 
is desired and insert this {nto the OBPL */ 
message_numb = extract_(p_ndm proc_ownerref, smessage.number_ad" )+1; 
eall aiter_{p_obpiref, obp].msg_ numb", message_numb); 
call alter_(p_obplref, "obpl.res_type", "message"); 


end; 
if entity_class_name_(p_ndm_proc_ownerref) = "op_con" 
en do; 
/* Get the name of the operator connection over which a message 
from an operator is desired #/ 
res_name = extract_(p_ndm_proc_ownerref, "op_con.name”") ; 
/* The resource (operator connection) is located entirely in 
one node, so the resource_node_name is the same as that of 
the node processing the OBPL *7 
res_node_name = p_rev_node_name; 
call alter_(p_obplref, "obpl.res_type", "op_msg"); 
end; 
/® Put the resource name and its node name into the OBPL #/ 
eall aiter_{p_obpiref, "obpl.res_name", res_name); 
call alter Pp obplref, "obpl.res_node_name", res_node_name) ; 
/* Check if the node can continue to expand the OBPL or if it must send the 
OBPL to another node */ 
if res_node_name = p_rev_node_name 
then p_eos = "1™b; 


else do; 
p_eos = "0"b:; 
; call del_obpl_cont_msg(p_obplref, res_node_name, p_rev_node_name); 
return: 
end OBPL: 
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%: 
REL: procedure: 
/* This procedure contains subroutines which allow processes 
to release resources and then assigns the released resource to a new 
process if pooeseres The following user visible function is included: 
RELEASE DATABASE OBJECT 
The following up rt routine is included: 
REMOVE PROCESS FROM QUEUE #/ 


del cont_msg_numb fixed bin; 

del dbo_name ehar(12); 

del dbdo_node_name char(12); 

del dboref fixed b nett}; 
del dbo_tableref . fixed bin(17); 
del eos bit(1); 

del ndm_proc_ownerref fixed bint a7) 
del ownerref fixed bin(17); 
del . dbo_name seat 

del p_dbo_node_name char(®); 

del p_dboref fixed bin(17); 
del p_dbo_tableref fixed bin(17); 
del pnoderef fixed bin(17); 
del p_process_name char(#); 

del p_proc_node_name char(#): 

del process_name char(12); 

del proc_node_name char(12); 

del procref fixed bin(17); 
del ptableref fixed bin(17); 
del res_ rel ref fixed bin(17); 
del sec_node_name ehar(12); 

del sh_asmtref fixed bin 1733 
del tableref fixed bin(17); 
del temp_name char(12); 

del write _list_ entry options(variable); 


Zinclude DDM_serv_routines:; 
Zinclude ADT_primitives: 
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/* RELEASE DATABASE OBJECT - 6/2/76 */ 

pereeeeOv es ce ceca) entry(p_proc_node_name, p_process_name, p_dbo_node_name, 

p_dbo_name); 

/* This procedure will cause the Proogne specified by nPeprocess name" (at 
node pproc_node name") to release its control over e database object 
specified by "p_dbo_ name" and located at the node specified by 
"pn dbo_node_name" # 

/* Verify that the node specified by "P_Proc node_name" exists */ 

if find_entity_loc(pnoderef, "sys->node”, SYS_REF, p_proc_node_name, 

"node.name"); 
then do; 
eail write list_("Invalid process node name. ", p_proc_node_name, 
Wdoes not exist"); 
return; 


end; 
/* Verify that the process specified by "p_process_name" exists at the node 
specified by "py proc_node_name" *%/ 
eos = find_entity_ 
PP oc_node_name, "node_table.name*): 
if find_entity_loc(procref, "node->process", ptableref, p_process_name, 
"process .name" 
then do; 
call write_list_("Invalid process name." Pyprocess_name, “at node", 
Pp_proc_node_name, "does not exis H 


oc(ptableref, "node->node_table", pnoderef, 


return; 


end; 
/* Verify that the node specified by "p_dbo_node_name" exists */ 
if find_entity_loc(dbo_tableref, "node->node_table", pnoderef, 
ee pd o_node_name, “"node_table.name" 
en do; 
eail write_list_("Invalid database object node name. ", 
p_dbo_node_name, "does not exist."); 
return; 


end; 

/* Verify that the database object specified by "p_dbo_name" exists at the 
node specified by "p_dbo_node_ name" and that the process specified by 
We Pag areal has access to it. #/ 

/* Verify that the node containing the process is aware of the existence of 

the database object #/ 
if sind ent ity—toe dboref, "node->dbo", dbo_tableref, p_dbo_name, "dbo.name") 
en do; 

eail write list_("Invalid release. Process", p_process_name, 
Wat node", p_proc_node_name, "does not have"); 

eall write_list_(" access to", p_dbo_name, "at node", 
p_dbo_node_name) ; 

return; 


end; 
/* Verify that the process has access to the database object *#/ 
if find_entity_loc(dboref, "pro ess->dbo" aati ee 3 dbo_name, "dbo.name") 


& empty_intersection_(procref process o_sh_asmt* dboref 
Sdboosubo : : ; 


do; 

call write list_("Invalid release. Process", p_process_name, 
at node", p_proc_node_name, "does not have"); 

call write_list_(" access to", p_dbo_name, "at node", 
p_dbo_node_name); 


sh_asmt") 


then 


return; 


end; 
/* Verify that He process is active */ 
call find_owner_(ndm_proc_ownerref, "node/dbo/mg->process", procref); 
if entity_class_name_(ndm_proc_ownerref) = "node_table" 

en do; ' 
call write list_("Invalid release. Process " p-process_name, 
é Wat node", p_proc_node_name, “is not active" " 

return; 


end; 
/* Check if the database object is at a node different from the one that 
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contains the process */ 


if P_p 


roc_| node_) 
hen do: 
/* R 


name = p_dbo_node_name 
elease the resource and send a resource rene message 


to the node which contains the database object * 
/* Check if there are no more "local® processes queued for the 


8 
if e 


/*® C 
a 
eall 


eall 
retu 
d: 


pecified remote database object * 
mpty_(dboref, "node/dbo/mg->process") 
hen do; 

/* If the process had exclusive control of the database 
object or if no other local process had shared access 
to the database object, then we can delete all local 
information about the remote database object 
otherwise just "release" the shared access of the 
process to the database ob Jeet e 

if inserted_(dboref, "process->dbo 

|~member_count. dboref’, Ondbo=>dbo sh_asmt") < 2 
then call delete_entity_(dboref, "dbo"); 


else d 
7s Find the gr rad for the involved dbo_sh_asmt 
and delete it 
eall Pea Creat cnt enbeck ices) (sh_asmtref 
"process=->dbo_sh_asmt", procref 
"dbo->dbo_sh_asmt", dboref, eos 
call delete_entity_(sh_asmtref, "dbo’ sh  asmt™); 
end; 


end; 
else do: 

/* Release the database ghee from access a the process, 
but retain other zocas nformation about the remote 
database object # 

if inserted_ lipseere "process=->dbo" ) 

then call remove_(dboref, "process->dbo"); 
else 
cail find_first_intersection_ (sh_asmtref 
nbrosces cba en asmt*, procref 
"dbo->dbo_sh_asmt", dboref, eos 
call delete_entity_(sh_asmtref, "dbo_sh asm") ; 
end 


end; 
reate an entity for a remote resource release and the declare it 
s a control beetay gabe 
create_ entity res_rel_ref, “res_rel"); 
create ttri ute (res_rel _ref, "res rei. rel_pnode_name", 
leld ) proc_} node name 
create geteibure pee rel ref ‘rea_pel. rel_proc_name", 
ield", 12, p_process_name) ; 
eebate attribute” (res_rel_ref, "res | rel.dest_node_name", 
"field" p_dbo_node_name) ; 
create attribute’ ( (res_rel_ref, "res_rel.dest_dbo_name", 
"Field", 12, p_dbo_name): 
del ry pte —hessage(res_rel_ ref, "res _) rel", cont. asthe SY 
insert £*cheont "sys->control_message", "last Svs her): 
write Toe necntrol message number" , cont_! ms numb, 
Wsent f from", p_proc_node_name, *to", p_dbo_node_name); 
write_list_(" representing a remote resource . release"); 
rn; 


en 

/* The next section will be executed if the process and database object are 
located in the same node *#/ 

/* Check if the process had exclusive control of the database object */ 

if inserted _(dboref, "process->dbo") 


t 


hen do; 
/* R 
p 


eal 


elease the database object and then grant at least one other 
rocess access to the database object if any processes are 
ueued for it. 

remove_(dboref, "process->dbo"); 
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call write_list_("Process", rocess_name, "at node" 
Pypred node ‘rhe neledaed database"); 
call write 4 at. Ob jeot",. p_dbo_name, "at soagh 


dbe_node_name) ; 

ie? apty_tdboref. hode/dbo/mg-> ") 

en cal Trad oioa trom meanetaberer: dbo_tableref); 
ae 

end; 


93 Release the database object from this shared assignment, and if 
there are. no o ocesses currently: having shared access to 
the database ob jest we ) can grant ae access to the 


else 


call dele 
call write_ 


os are Se, Sait 
then - onli boref, dbo ‘eabierer)’ 


return: 
end; 
/* more PROCESS E QUEUE e73/i6 #/ 
pemaproc_fre queue: ry {a_doorer p_dbo... -tableref 
dre will ena’ on access to the database 
objes rthat is Nerersaned ty xe re and is loca } in the node that 
has its own node_ table referenced by "p_dbo_ tableref™). If the first 
process on the que ante exolusive uaé.of the: ob ject then 
only this prese ed access, te, bhe dha, 0 othe: a¢ all 
' processes t reque d ncdesa and shige in the 
queue) of all progdageg Enat . ested exclusive use will be given 
/* Pind the First. process guened the detanape ject #/ 
n objec 
ogil Cneoke TF the tlproere: Vdbo/aae prone boref, eos); 
Check if the nt at wants aualuaive - + @ object #/ 
it extrac t_(procr "process. evoesa_type™): s. ‘Wexelusive" 
en do; 


72 vapnoae une -Prooess ot "node->process", rocref ); 
*node/dbo/ng=>proceas® “5 f 


call remove_(procref, 4 
call insert_(proonp: "node/dbo/ "first", aornerref); 
ai faut Goer eee sere 

et the names of the proce s.be. dnd nosee’ {vo ved */ 


dbo_name = extract, (pd Bren n A 
dbo_node_name = extract _(p_: dbo, dbo -nanat node. wh pPhe- -nanie"); 
pecees ame = extract_(procref, "process. name™ 
proc e name = extract_(ownerref, "node_table.name"); 
/*® Check If the peccene ® gaining access to the database "object is in 
the same node as 
if proc c_node_ ) name = abe vnoda nas 
hen do; 
eall write ("Process" , process_name, "at node" 
a i is given exclusive use oft); 
eall writ Pris , dbo_name, "at node*, 
ode_name) ; 

return; 
e e 
else d 


/* Create a control message for a remote resourc 
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else 


return: 
end REL: 


allocation and send it across nodes. */ 
call del_rem_res_grant(dbo_node_name, dbo_name, 


proc_node_name, process_name, cont_msg_numb); 
call write list_("Controi message number" , cont_msg_numb, 
Wsent from", dbo_node_name, "to", 


proc_node_name); 
eall write _list_(" ranting", process vane: 
Wexclusive use of", dbo_name); 
return; 
end; 


end; ~ 
do while (“eos); 
/* The first process on the queue requested shared access */ 
/* Unblock the process * 
call find_owner_(ownerref, "node->process", proeret); 
eall reacve_/procret; "node/dbo/mg->process" ); 
call insert_(procref, "node/dbo/mg->process", "first", ownerref); 
/* Give the process shared access to the database object */ 
call del_dbo_sh_asmt(sh_asmtref); 
call insert_(sh_asmtref, "dbo->dbo sh_asmt", "first", P dboref ); 
call insert_(sh_asmtref, "process->dbo_sh_asmt", "firs a procref); 
/* Get the names of the process, dbo and nodes {nvolved #, 
dbo_name = extract_(p_dboref "dbo. name"); 
dbo_node_name = extract. (p_dbo. tableref, "node_table.name"); 
process_name = extract_(procref, "process.name"™); 
proc_node_name = extract_(ownerref, "node_table.name"); 
/* Check {f the process gaining aecess to the database object is in 
the same node as the dbo *#/ 
if proc_node_name = dbo_node_name 
then do; 
call write_list_("Process", process_name, “at node", 
proc_node_name, "is granted shared access to"); 
call write_list_(*" ", dbo_name, "at node", 
dbo_node_name); 
end; 
else do; 
/* Create a control message for a remote resource 
allocation and send it across nodes. */ 
call del_rem_res_grant(dbo_node_name, dbo_name, 
proc ne e_name, process_name, cont_msg_numb); 
call write list_ ("Control message number" cont_msg_numb, 
Wsent from", dbo_node_name, "to", 
proc_node_name); 
eall write _list_(" anting", Reverse ene 
shared access to", dbo_name); 


end; 

/* at wnat is now the first process queued for the database 
objec 

call find _first_(procref, "node/dbo/mg->process", p_dboref, eos); 

/* If this process wants exclusive control of the database object it 
must remain blocked and we will not remove any more processes 
from the queue */ 

if extract_(procref, "process.access_type") = "exclusive" 

; then eos = ninb; 
end; 
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DM_serv_routines.incl.pl1 


DDM_serv_routines 


/# 
The followina declarations are of the DDM service poutipes 
del check _f lock 


del 
del 
del 


del 
del 


del 


del 


del 
del 
del 


del 


del 


del 


del 


del 
del 


or_dead. 


dol_ dbo 
dol. 
dol_control_pessage 


dol, node_tab 
dol_obp1 


/* Located within: P 


/* Located within 
dcl_obpl_cont_mag 


/* Located within 
del_proc_entry 


/* ‘Located within 


del. process 
al ; i bela Located within P 


/* Located within 
find_entity_. ais 
/* Located within. 


exp_obpl 
/* Located: within 
initiate _obpl 


/* Located within P 


| enery fixea bt 17), fixed bin(17), 
part?! 2) yfEty: 


obp]_add_resource 


/* Loeated within: P 
on_p (fix 17), tt dad bin(17)); 
i is fooated within Ptapelyre Re R baa n oe if 
try (char 25 


rldbo 


/* Located within Proced 


a/ 
ent: fixed a ) r(12), 
ery ria 33? ' he $3 

/* Located within prooes re 0. 
/* Located within Pros 
 Loaated within Proo 


Fleed ed bn 17), char(12)); 
fixed od g.n(17)): : 

20), 
Pg a0SD, ohar( ) 


Pixea roca, ehar(12)); 


DDM 
entry(fixed bint! ), ohar (1 ), 
Sa bie 12); ober 07993" 
Gace bi {30}: char(12), 
ite” st) char(12), 


entry earoe char(*), ehar(12).); 
yloner C2, erin phen le); 
xed b: 


sate aed bint7) rebar 


og pap i7), onar(12)4 


or oH 17), char(12)); 


ee 


qnarti2), ener(7)Ss 


tH,” gharc®, char(*), 


/* Located within Procedure REL */ 
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/*75-12-29 ADT_primitives.inel.p 
These are ADT primitives designed to assist the fu Pat on _shagt1285) writer *#/ 
del add_ entry eben Veeee ), char cae 
returns (ch ng); 
del alter_ entry (Fixed bintinys eat ah 
del append_ entry fined. bin(17), Ree): 
har(6) fixed bin(17)); 
del break_ entry{ fixed bin(17)); 
del create_attribute_ entry(fixed bin(17), char(44), 
ehar SF ixed bin(17), 
del create_catalog_object_ entry (fixed bin 17), char(#) 
del create_entity_ entry(fixed bin . char(20 F 
del create_group_ entry(fixed bin(1 char : 
del create_order_ entry (fixed ban 17); char(20), 
del create_relationship_ entry (fix d bin(17), char(20), 
e 
del deleted_ entry (fixed bin( 17 2) sserteessin 
del delete_entity_ entry(fixed b i, M 
del divide_ entry(char(1 ue 
returns Chard 12 varying): 
del empty__ main Ci xed CEH}. 
del empty_intersection_ entry fee bin(1 , char 20 
ix bin(1 char(20))’ 
erastbit 1335 
del entity_class_name_ entry (fixed rest 
returns(char(20)); 
del entity_order_name_ entry( fixed arene char(20)) 
returns(bit(1)}; 
del exception_ entry 
del extract_ entry( fixed pene ghar (44) ) 
returns (char 138) ing); 
del find_associatively_ entry( fixed ere ohae }» 
Fee ha pac | Py raked varying, 
del find_catalog_object_. entry(fixed gle 17); char(® ) 
del find_direct_ entry(fixed bin(17), char(*)); 
del find_each_ entry(fixed bin(17), bit(1)); 
del find_first_ entry(fixed bi i : char 0}, 
fixed bin(17 bit(1 
del find_first_intersection_ enery (fixed bin(1 i, char (26 ; 
deed eet] sith 
ize n ‘ 
del find_first_union_ entry (fixed binds }, char(20), 
ixed bin iy , char(20), 
ixed bin(1 bit(1)); 
del find_last_ entry fixed bi bi (175, ogner 36), 
del find_next_ entry( fixed *ncTS, char(20), 
del find_next_intersection_ entry (Fixe Bin 17), ot har(20), 
del find_next_union_ entry) fixer iat ); char(20), 
xed ¢ PEt y > peta) 
del find_owner_ entry (fixed bi HOE Satie 
del find_prior_ entry (fixed bin(17 : ehar(20), 
del insert_ entry. tixee bin(17), ehar(20), 
xe n 
del inserted_ entry(fixed rift {17} 1305) 
returns(bit(1)); 
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del last_of_set_ enkry tized piety char(20)) 
returns (bit(1)); 

del member_ entry(fixed bin(17), char(20)) 
returns (bit(1)); 

del member_count__ entry (fixed hee ohar(30)) 
returns Crixed bin(17)) 

del name_catalog object_ entry(fixed bi pin(t7) 4 
returns ( ) aie 

del multiply_ entry (char (128) quar lee 8 
returns(char(12 ing); 

del owner _ entry(fixed bin(17 sare 0) 
returns(bit(1)}; 

del remov entry) eixed Piatt ; “har (20); 

del sort. vrelationship_ entry ahanico bin(17), char(20 

del subtract_ entry Conant 126); oben ien)) 
returns(char(12 arying); 

/* The following are global reference variables used by modellers 

del Senge” fixed bin(1 external beet las 

del fixed bin if external static init(0); 

del CN_REF fixed bin(17) external static init(0); 

del PROC_REF fixed bin(17) external static init(0); 

del PSPH_REF fixed bin i external static init(0); 

del PSSG_REF fixed bin(1 external static init(0); 

del return_code fixed Bidees jee ions static init(0); 

del SYS_REF fixed bin(17) external static init(0): 

del tracemode bit(1) SEER. static init("0"b); 
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This appendix contains examples of several deadlock and "near deadlock" 
situations, thus demonstrating various features of the deadlock detection al- 
gorithm presented in Chapter VI. In the case where a deadlock is detected, a 
final state diagram is given, whereas in the examples where no deadlock is 
detected, an important intermediate state {is also shown. A key to the 
diagrams appears on the next page. Diagrams appear on a page with a header 
containing the name(s) of the associated scenario(s). Each diagram immedi- 
ately follows the first scenario with which it is associated. 

It should be noted that before the commands specific to each example were 
executed, after the system state was reinitialized, the commands in file 


"demo0" were executed. 
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city 


Key for State Diagrams of Demonstration Scenarios 


Represents process "pi" as the initiator of message 


group "mej". () and Tag are always in the same 
node for this representation. 


Represents process "pi" as the acceptor of message 
group "mgj" and "pi" is currently waiting for a mes- 
sage in "mgj". @) and TaN need not be in the 


same node for this representation. 


Represents process "pk" waiting for a message from 


operator "opi" over operator connection "conj". 


Represents operator "opi" waiting for a message from 


process “pk" over operator connection "conj". 


Represents process "pi" as having access to database 
object "dbok". The type of access is specified by 


"access_type". ()) and need not be in the 


same node. 


Represents process "pi" as waiting for access to 
database object "dbok". The type of access desired 


is specified by "access_type". @}) and need 
not be in the same node. 


Represents a node with the node name specified by 
"oity"™, @3) and drawn "within" this node 
represent processes and database objects located 
within the node specified by "city". Saad, drawn 
“within” the node represents a message group that was 
initiated by a process located in the node specified 
by "city". 
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scenario demo0 
sysgen 

System created 
enode Boston 


Node created: Boston 
enode Phoenix 
Node created: Phoenix 


eproc Boston p1 


Process pl created in node Boston 
eproe Boston p2 

Process p2 created in node Boston 
eproc Boston 

Process created in node Boston 


edbo Boston dboi 

Database ob a dbo1 
edbo Boston dbo2 

Database object dbo2 
eproc Phoenix 


created in node 
created in node 


1 
Ph created in node 


Process Phoenix 
eproc Phoenix 2 
Process p ereated in node Phoenix 
eproc Phoenix 
p aa ben in node Phoenix 


Process 
edbo Phoenix dbo! 
Database object dbo 
edbo Phoenix dbo2 
Database object dbo2 
enode conor one 
Node create 
eproc Cambridge 


ereated in node 
created in node 
s eaebrecee 


Process pl Peates in node Cambridge 
eproc Cambridge p2 

Process ape created in node Cambridge 
eproc Cambridge p3 

Process p3, created in node Cambridge 


edbo Compr eee dbo1 
Database o gect dbo1 

edbo Seeeplghe Sri bo2 
Database object dbo2 


created in node 
created in node 
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Boston 


Boston 


Phoenix 


Phoenix 


Cambridge 
Cambridge 


Appendix III scenario demo_bug 


scenario demo_bug 


note This is an example of a case where a deadlock eavel ane two 
note processes and two resources located in two nodes is detected, 
note when in fact no deadlock exists. The reason a deadlock is 

note detected is that an OBPL sent from Boston to Phoenix had its 
note arrival delayed long enough so that pi in Phoenix could release 
note dbo1 in Boston pequere access to it again, gain use of the 
note database object and then request access to and pet ueued for 
note dbo1 in Phoenix before Phoenix examined the OBPL. he first 
note seven commands set up the state where p1 in Phoenix has exclusive 
note use of dbo1 in Boston, p1 in Boston has shared use of dbol in 
note Phoenix, p1 in Boston is blocked waiting for shared use of dbo! 
note in Boston, and an OBPL has been sent to Phoenix by Boston. 


rqdbo shared Boston p1 Phoenix dbo! 
Process e) at node Boston is blocked while a request is sent to 
he node containing the desired resource 
Control message number 1 sent from Boston to Phoenix 
representing a remote resource request 


revenm 1 
Control message number 1 representing a remote resource request 
has been received 
p1 at node Boston is granted shared access to 
dbo1 at node Phoenix 
Control message number 2 sent from Phoenix to Boston 


; representing this allocation 
revem 
Control message number 2 representing a remote resource allocation 
has been received 
pl at node Boston has been granted shared access to 
dbol at node Phoenix 
rqdbo exclusive Phoenix p1 Boston dbol 
Process 1 at node Phoenix is blocked while a request is sent to 
he node containing the desired resource 
Control message number 3 sent from Phoenix to Boston 
3 representing a remote resource request 
revem 
Control message number 3 representing a remote resource request 
has been received 


pi at node Phoenix is granted exclusive use of 
dbo at node Boston 
Control message number 4 sent from Boston to Phoenix . 


‘ representing this allocation 
revem 
Control message number 4 representing a remote resource allocation 
has been received 
p1 at node Phoenix has been granted exclusive use of 
dbo at node Boston 
rqdbo shared Boston p1 Boston dbol 
Resource not available, process blocked. 


Control message number sent from Boston to Phoenix 
representing an OBPL 
note Do not let the OBPL be received at this time. Let p1 in Phoenix 
note release dbo1 in Boston, so that p1 in Boston will be awakened and 
note granted shared use of dbo1 in Boston. 


ridbo Phoenix p1 Boston dbo1 
Control message number 6 sent from Phoenix to Boston 
representing a remote resource release 
revem 6 
Control message number 6 representing a remote resource release 
has been received 


dbo1 at node Boston has been released by 
p1 at node Phoenix 
Process p1 at node Boston is granted shared access to 
dbo at node Boston 
note Let p1 in Phoenix request access to dbo1 in Boston for the 
note second time, and let it be granted shared use of the database 
note object. 
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rqdbo shared Phoenix pi Boston dbol 

Process 1 at node Phoenix is blocked while a request is sent to 

he node containing the desired resource 
Control message number 7 sent from Phoenix to Boston 
7 representing a remote resource request 

revem 

Control message number 7 representing a remote resource request 

has been received 


p1 at node Phoenix is granted shared access to 
dbo1 at node Boston 
Control message number sent from Boston to Phoenix 


8 representing this allocation 
revem 
Control message number 8 representing a remote resource allocation 
has been received 


pl at node Phoenix has been granted shared access to 
dbo at node Boston 
note Let pl in Phoenix request exclusive use of dbo1 in Phoenix. 
note The process will be blocked and an OBPL will be sent to Boston 
note where it will be discarded because p!1 in Boston is active. 


rqdbo exclusive Phoenix p1 Phoenix dbo 
Resource is not currently available for exclusive use, process p1 
at node Phoenix is blocked. 
Control message number 9 sent from Phoenix to Boston 
representing an OBPL 


revem 9 

Control mensage number 9 representing an OBPL has been received. 
note Now let Phoenix receive the OBPL that was previously sent by 
note Boston. A "false" deadlock will be detected because p1 in Phoenix 
note is blocked and has access to dbol in Boston, even though this is 
note not the same assignment of the resource that was used when the 
note é OBPL was created. 
reven 


Control message number 5 representi an OBPL has been received. 
A deadlock has been detected. The fol alas 14 eae are involved: 
pi at node ston 

p1 at node Phoenix 
End of deadlock list 
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exclusive 


shared 


Boston Phoenix 


State where control message 5 representing an OBPL has just been sent 
from Boston to Phoenix. Receipt of the OBPL is delayed until after the state 
drawn below has drawn been reached. 


shared 


Boston Phoenix 


Final State Diagram 
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scenario demo! 


note This is an example of a two process two resource deadlock ina 
note single node. No control messages and no operators are involved 
note in the detection of this deadlock. 


initmg mai Boston p2 Boston 
Message group mgi_ has been initiated 
noceptne mg1 Boston p1 
mel has been acceptee by P! at node Boston 
rqd shared Boston pl Boston dbo! 
pi at node Boston granted shared access to dbo! at node Boston 
rqdbo exclusive Boston p2 Boston dbo! 
Resource is not currently available for exclusive use, process p2 
at node Boston is blocked. 
revmsg mgt 
Process pi at node Boston is blocked waiting for a 
message in mesonee group mei 
A deadlock has been detected. The Foot  bsbecoennee are involved: 
pi at node 3oston 


p2 at node Boston 
End of deadlock list 


Boston 


Final State Diagram 
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scenario demo2 
note This is an example of a two process two resource deadlock 


note involving two nodes. The first three commands create the state 
note where both processes are active and both involved resources have 
note been allocated to the proper processes: 

rqdbo exclusive Phoenix pi Phoenix dbo 


als at node Phoenix S granted exclusive use of dbol at node Phoenix 
initmg mg2 Cambridge p1 Phoenix 
Message group mg2 has been initiated 
acceptmg mg2 Phoenix p1 
age has been accepted by pl at node Phoenix 
rqdbo shared Cambridge p1 Phoenix dbo!l 
Process pl at node Cambridge is blocked while a request is sent to 
he node containing the desired resource 
Control message number 1 sent from Cambridge to Phoenix 
7 ae th nes pe) a remote resource request 
e 


note 11 delay the receipt by Phoenix of this resource request. 
revmsg mg2 
Process pt at node Phoenix is blocked waiting for a 
message in message group mg2 
Control message number 2 sent from Phoenix to Cambridge 


3 representing an OBPL 
revem : 
Control message number 2 representins an OBPL has been received. 
Control message number 3 sent from Cambridge to Phoenix 
representing an OBPL 


note This OBPL contains entries for p1 in Phoenix and p1 in Seapdaeingg Sak 
note It will be discarded by Phoenix because Phoenix has no record that 
note pi in Cambridge is waiting for dbo! in Phoenix since control 

note 3 message 1 still has not been received. 

reven 


Control message number 3 representing an OBPL has been received. 
revem 
Control message number 1 representing a remote resource request 
has been received 
Resource not available, process remains blocked. 


Control message number sent from Phoenix to Cambridge 
pepranent’n6 an OBPL 
note This OBPL contains entries for p1 in Cambridge and p1 in Phoenix. 


note It states that pi in Phoenix is waiting for a message in message 
note group mg2. Cambridge will very that the desired message has 
note k not been sent, and a deadlock will be detected. 
revem 
Control message number 4 popresene ue an OBPL has been received. 
A deadlock has been detected. The fol owing processes are involved: 
pi at node ambridge 
pi at node Phoenix 
End of deadlock list 
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exclusive 


Phoenix Cambridge 


Final State Diagram 
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seenario demo3 


note This is an example of a two process two resource deadlock 

note involvi two nodes. The first three commands create the state 
note where both processes are active and both involved resources have 
note been allocated to the proper processes: 

rqdbo exclusive Phoenix p1 Phoenix dbo 


p at node Phoenix S granted exclusive use of dbo1l at node Phoenix 
initmg mg2 Cambridge p1 Phoenix 

Message group mg2e has been initiated 
accep tae mg2 Phoenix p1 

ng has been accepted by P at node Phoenix 
rqdbo shared Cambridge p1 Phoenix dbol 

Process Pp at node Cambridge is blocked while a request is sent to 

he node containing the desired resource 

Control message number 1 sent from Cambridge to Phoenix 
7 Fopreren ane a remote resource request 

e 


note 11 dela receepY by Phoenix of this resource request just 
note long enough to block p1 in Phoenix (which controls dbol in Phoenix) 
note and send an OBPL to Cambridge. In this way, after receipt of the 
note resource request, we will have two OBPL's outstanding, and the same 
note deadlock will be detected twice. 
revasg mg2 

Process pi at node Phoenix is blocked waiting for a 

message in message er oup mgz2 
Control message number 2 sent from Phoenix to Cambridge 
; representing an OBPL 

revcm 


Control message number 1 representing a remote resource request 
has been received 
Resource not available, process remains blocked. 
Control message number sent from Phoenix to Cambridge 
representing an OBPL 
revem 2 
Control message number 2 peppescnt {ng an OBPL has been received. 
Control message number 4 sent from ambridge to Phoenix 
representing an OBPL 
revem 3 
Control message number 3 eer ecene. oe an OBPL has been received. 
A deadlock has been detected. The fol ria processes are involved: 
pi at node ambridge 
pi at node Phoenix 
End of deadlock list 
revem 4 


Control message number 4 represent ne an OBPL has been received. 
A deadlock has been detected. The fol owing processes are involved: 
pi at node hoenix 

pi at node Cambridge 
End of deadlock list 
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scenario demo4 


note This is an example of a two process two resource deadlock 
note povoryene two nodes. The first three commands create the state 
note where both 


pEcoesrer are active and both involved resources have 
note been allocated to the proper ERO Oe Ree: 
rqdbo exclusive Phoenix p1 Phoenix dbo 
pe at node Phoenix s granted exclusive use of dbo! at node Phoenix 
initmg mg2 Cambridge p1 Phoenix 
Message eroup mg2 has been initiated 
sb ag mg2 Phoenix p1 
has been accepted by pl at node Phoenix 
rad shared Cambridge p1 Phoenix dbo 
Process Pp at node Cambridge is blocked while a request is sent to 
he node containing the desired resource 
Control message number 1 sent from Cambridge to Phoenix 
representing a remote resource request 


note We will allow this resource request to be immediately received 
note by Phoenix. No OBPL will be generated because rh in Phoenix is 
note active, and it controls dbo1 In Phoenix. By default, control 
note messages generated in the future will be received immediately 
note ; after they are sent, and the deadlock will be detected once. 
revem 


Control message number 1 representing a remote resource request 
has been received 
Resource not available, process remains blocked. 
revmsg mg2 
Process p1 at node Phoenix is blocked waiting for a 
message in message group mg2 
Control message number 2 sent from Phoenix to Cambridge 
representing an OBPL 
revem 2 
Control message number 2 representing an OBPL has been received. 
Control message number 3. sent from ambridge to Phoenix 
representing an OBPL 
revem 3 
Control message number 3 pepr essen e an OBPL has been received. 
A deadlock has been detected. The fol Suing processes are involved: 
pi at node hoenix 


p1 at node Cambridge 
End of deadlock list 


156 


Appendix III scenario demo5 


scenario demo5 
note This is an example of a state where two deadlocks exist 


note onvorysn four processes and Four ‘ecause dbo Acca ted in three 
note nodes. deallooks are. Baits aed ecause dbo! in.Cambridge 
note has two shared: user 0. are eative 8 vareate. the state 
nove where all be ea petit bs ae J-all the involved 
resourdes ha rooeas 0. the gesses. 

ind tmg mgi Boston pi Casbridge. 

Message group mg! has deen initiated 
acceptme mg! Cambridge p1 

mg? has been opto by Pi at node Cambridge 
rad idge pl Cambridge dbo! 


p! n ambridge anted shared access to dbol at node Cambridge 
raqdbo shared Boston p!1 ‘idge dbo1 
Process ie at nods ton...is blocked. while a request is sent to 
ling the desired resource 
Control meesige fi Raber 1. sent from. Beaton to. Cambridge 
; representing a remote resource request 
revcn 


Control message number 1 representing a remote resource request 
has been received 


pi at node Boston is granted shared access to 
abot es a node Cambridge ; 

Control message number from Gambcy cae to Boston 

5 representing this allocation 
reven 
Control mesange number 2 cs representing a remote resource allocation 
as mn receive 

p1 at node Botan, as beén. oranted. ‘shared access to. 

dbot at node Cambri dee ; 


madbe exclussre Cambridge, pe idge, is blocked pee 4 rs 
rocess a Cambri ear st is sen 
the node cotr ne’ the doetre ee Kae 
Control message number 3 mori ige ‘to Phoenix 
3 representing a remote resource reque 
rever 
Control Pr esenti a remote resource request 
rg ges peoedy wad pestle oe ies 
at node Cambridge is granted exclusive use of 


dbo nen Phoenix. 
Control message ent from Phosnix to Cambridge 
repres ee "this allocation 


revem 4 
Control Wran bear rene 4 representing a remote resource allocation 
mn received 
p2 at node Cambridge has been aranted. exclusive use of 
ad t node oa 


mix ¢ 
pi ted s | access to dbo2 at node Phoenix 
rqiibo exclussve Boston p 


oenix 
Process Pp at node Boston is blocked while a request is sent to 
he node oonnat eens the desired resource 
Control message number 5 sent from Boston ee Phoenix 
re resenting @ remote resource request 
note No OBPL will sent to another node, and no deadlock will 
note be detected because p! at node Ph hoenix is active and is the only 
note 5 process that has access to dbo2 in Phoenix. 
reven 
Control moose pooh eon representing a remote resource request 
rg recei 
Resource ie not Gurrentie. available for exclusive use, process p! 
at node Boston remains blocked 
rqdbo shared Phoenix } Phoenix dbo! 
Resource not available, process blocked. 
Control message number sent from Phoenix to Cambridge 
representing an OBPL 
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note 6 No deadlock will be detected because p2 in Cambridge is active. 
revem 

Control message number 6 representing an OBPL has been received. 
note This next request will create a three process three resource 
note deadlock. An OBPL will be created, arid we will immediately pass 
note it from node to node in order to detect the deadlock. 


rqdbo exclusive Cambridge p2 Cambridge dbo1 
Resource is not currently available for exclusive use, process p2 
at node Cambridge is blocked. 
Control message number 7 sent from Cambridge to Boston 
representing an OBPL 


revem 7 
Control message number Fs representing an OBPL has been received. 
Control message number sent from ston to Phoenix 


8 representing an OBPL 
revem 
Control message number 8 representi an OBPL has been received. 
A deadlock has been detected. The fol evEne processes are involved: 
8 


p2 at node mbridge 
pi at node Boston 
pi at node Phoenix 
End of deadlock list 
note The next command will create a four process four resource deadlock. 
note Due to the faet that two processes have shared access to dbo in 
note Cambridge, both this newly created deadlock, and the previously 
note detect deadlock will be detected when the OBPL is created and 
note passed among the nodes. 
revmsg mg} 
Process pi at node Cambridge is blocked waiting for a 
message in message group mg 
Control message number 9 sent from Cambridge te Boston 
representing an OBPL 
revem 9 
Control message number 9 representing an OBPL has been received. 
Control message number 10 sent from Boston to Phoenix 
representing an OBPL 
rovem 10 
Control message number 10 representing an OBPL has been received. 
Control message numbér 11 sent from Phoenix to Cambridge 
e representing an OBPL 
reven 


Control message number 11 representing an OBPL has been received. 
A deadlock has been detected. The following processes are involved: 
pi at node vambridge 
pl at node Boston 
pl at node Phoenix 
pe at node Cambridge 
End of deadlock list 


A deadlock has been detected. The FOr LoMine processes are involved: 
pi at node 3oston 
pl at node Phoenix 


p2 at node Cambridge 
End of deadlock list 
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(1) exclusive 


shared 


Boston Phoenix 


shared exclusive 


shared 


exclusive 


Cambridge 


Final State Diagram 
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scenario demo6 


note This is an example of a state where two deadlocks exist 

note involving four processes and four resources located in three 
note nodes. © deadlocks are involved because dbo! in Cambridge 
note has two shared users. The first 10 commands create the state 
note where all the involved processes are active and all the involved 
note resources have been allocated to the proper processes. 


initmg mg1 Boston pi Cambridge 

Message group ‘EP has been initiated 
acceptmg mgi Cambridge p1 

mg has been accepted by pt at node Cambridge 
rqdbo shared Cambridge p1 Cambridge dbo} 

p1 at node Cambridge granted shared access to dbol at node Cambridge 
rqdbo shared Boston pi Cambridge dbo1 

Process e at node Boston is blocked while a request is sent to 

he node eontaining the desired resource 
Control message number 1 sent from Boston to Cambridge 
4 representing a remote resource request 

revem 

Control message number 1 representing a remote resource request 

has been received 


pl at node Boston is granted shared access to 
dbo at node Cambridge 
Control message number 2 sent from Cambridge to Boston 


‘ representing this allocation 
revem 
Control message number 2 representing a remote resource allocation 
has been received 
pl at node Boston has been granted shared access to 
dbol at node Cambridge 
radbo exclusive Cambridge p2 Phoenix dbol 
Process pe at node Cambridge is blocked while a request is sent to 
he node containing the desired resource 
Control message number 3 sent from Cambridge to Phoenix 
3 representing a remote resource request 
revem 
Control message number 3 representing a remote resource request 
has been received 


p2 at node Cambridge is granted exclusive use of 
dbo at node Phoenix 
Control message number 4 sent from Phoenix to Cambridge 


4 representing this allocation 
reven 
Control message number 4 representing a remote resource allocation 
has been received 
pe at node Cambridge has been granted exclusive use of 
dbol at node Phoenix 
rqdbo shared Phoenix p1 Phoenix dbo2 
pt at node Phoenix ranted shared access to dbo2 at node Phoenix 
rqdbo exclusive Boston p1 Phoenix dbo2 
Process 1 at node Boston is blocked while a request is sent to 
he node containing the desired resource 
Control message number 5 sent from Boston to Phoenix 
representing a remote resource meaeee 
note p1 in Phoenix is active, so there will be no deadlock when the 
note 5 remote resource request is received from Boston. 
revem 
Control message number 5 representing a remote resource request 
has been received 
Resource is not currently available for exclusive use, process p1 
at node Boston remains blocked 
radbo shared Phoenix pi Phoenix dbol 
Resource not available, process blocked. 
Control message number sent from Phoenix to Cambridge 
representing an OBPL 
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note pe in conor cage is active, so the OBPL will be discarded after 
note 6 t is received by Cambridge. 
revem 

Control message number 6 representing an OBPL has been received. 
revmsg ngi 


Process pi at node Cambridge is blocked waiting for a 
message in message group mei 
Control message number 7 sent from Cambridge to Boston 


representing an OBPL 


note Pe in Cambridge is active, so the OBPL will be discarded when 
note 1 t reaches Cambridge. 
revem 
Control message number Fs per eeent ene an OBPL has been received. 
Control message number sent from oston to Phoenix 


3 representing an OBPL 
revem 
Control message number 8 hate an OBPL has been received. 
Control message number 9 _ sent from hoenix to Cambridge 
representing an OBPL 


revem 9 

Control message number 9 representing an OBPL has been received. 
note This next request will create two deadlocks, due to the fact that 
note dbo1 in Cambridge has two readers. Two OBPL's will be generated, 
note and both deadlocks will be detected when their respective OBPL's 
note arrive in Phoenix. The OBPL's need not return to ear” 
note because p2 in Cambridge was the first process to be placed in the 
note OBPL's, and Phoenix knows that p2 in Cambridge controls dbo! 
note in Phoenix. 


rqdbo exclusive Cambridge p2 Cambridge dbo1 
Resource is not currently available for exclusive use, process p2 
at node Cambridge is blocked. 


Control message number 1 sent from Cambridge to Boston 
representing an OBPL 
Control message number 11 sent from Cambridge to Boston 
representing an OBPL 
revem 10 
Control message number 10 representing an OBPL has been received. 
Control message number 12 sent from ston to Phoenix 
representing an OBPL 
revem 12 
Control message number 12 representing an OBPL has been received. 
A deadlock has been detected. The fol loving processes are involved: 
p at node ambridge 
pi at node Cambridge 
pi at node Boston 


pl at node Phoenix 
End of deadlock list 
revem 11 


Control message number 11 peprenentsne an OBPL has been received. 
Control message number 13 sent from Boston to Phoenix 
representing an OBPL 
revem 13 
Control message number 13 representing an OBPL has been received. 
A deadlock has been detected. The following processes are involved: 
p2 at node ambridge 
pl at node Boston 


pl at node Phoenix 
End of deadlock list 
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scenario demo7 


note This is an example of a state where three deadlocks exist 

note cnvervine six processes and five resources located in three 

note nodes. hree deadlocks are involved because dbo2 in Boston 

note has three shared users. Five, rather than six, resources are 
note involved because two processes are waiting for the same database 
note object. The first 18 commands create the state where all the 
note involved processes are active and all the involved resources 
note have been allocated to the proper processes. 


rqdbo shared Boston p1 Boston dbo2 
e at node Boston granted shared access to dbo2 at node Boston 
initmg mgz1 Phoenix p1 Boston 
Message group mg1_ has been initiated 
accepting mg1i Boston p1 
mg has been aceeptes by p1 at node Boston 
radbo exclusive Phoenix p2 Boston dbo! 
Process p2 at node hoenix is blocked while a request is sent to 
the node containing the desired resource 
Control message number 1 sent from Phoenix to Boston 
; representing a remote resource request — 
revem 
Control message number 1 representing a remote resource request 
has been received 


p2 at node Phoenix is granted exclusive use of 
dbo! at node Boston 
Control message number 2 sent from Boston to Phoenix 


; representing this allocation 
revem 
Control message number 2 representing a remote resource allocation 
has been received 
p2 at node Phoenix has been granted exclusive use of 
dbo1 at node Boston 
rqdbo shared Cambridge p1 Boston dbo2 
Process Pp at node Cambridge is blocked while a request is sent to 
he node containing the desired resource 
Control message number 3 sent from Cambridge to Boston 
3 representing a remote resource request 
reven 
Control message number 3 representing a remote resource request 
has been received 


pi at node Cambridge is granted shared access to 
dbo2 at node Boston 
Control message number 4 sent from Boston to Cambridge 
4 representing this allocation 
reven 


Control message number 4 representing a remote resource allocation 
has been received 
pl at node Cambridge has been granted shared access to 
dbo2 at node Boston 
rqdbo shared Cambridge p2 Boston dbo2 
Process 2 at node Cambridge is blocked while a request is sent to 
he node containing the desired resource 
Control message number 5 sent from Cambridge to Boston 
re reneee te a remote resource request 
rqdbo shared Phoenix p! Cambridge dbo! 
Process a at node Phoenix is blocked while a request is sent to 
he node containing the desired resource 
Control message number 6 sent from Phoenix to Cambridge 
5 representing a remote resource request 
revem 
Control message number 5 representing a remote resource request 
has been received 


pe at node Cambridge is granted shared access to 
dbo at node Boston 
Control message number 7 sent from Boston to Cambridge 


representing this allocation 
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revem 6 
Control message number 6 representing a remote resource request 
has been received 


pl at node Phoenix is granted shared access to 
dbo1 at node Cambridge 
Control message number 8 sent from Cambridge to Phoenix 


7 representing this allocation 
revem 
Control message number 7 representing a remote resource allocation 
has been received 
p2 at node Cambridge has been granted shared access to 
dbo2 at node Boston 
revem 8 
Control message number 8 representing a remote resource allocation 
has been received 
p1 at node Phoenix has been granted shared access to 
dbo1 at node Cambridge 
rqdbo exclusive Cambridge p3 Phoenix dbo1 
Process p3 at node Cambridge is blocked while a request is sent to 
he node containing the desired resource 
Control message number 9 sent from Cambridge to Phoenix 
9 representing a remote resource request 
revem 
Control message number 9 representing a remote resource request 
has been received 


p3 at node Cambridge is granted exclusive use of 
dbo at node Phoenix 
Control message number 10 sent from Phoenix to Cambridge 


+6 representing this allocation 
revem 
Control message number 10 representing a remote resource allocation 
has been received 


p3 at node Cambridge has been granted exclusive use of 
dbo1 at node Phoenix 
revmsg mei 
Process pi at node . Boston is blocked waiting for a 
message in mesonse group mg! 
Control message number 1 sent from Boston to Phoenix 
representing an OBPL 
note - The OBPL will be discarded by Phoenix because p1 is active. 
revenm 


Control message number 11 representing an OBPL has been received. 
rqdbo shared vanprrcce pi Boston dbo1 
Process Pp at node Cambridge is blocked while a request is sent to 
he node containing the desired resource 
Control message number 12 sent from nanr aces to Boston 
representing a remote resource reques 


note The eats that controls dbo! in Boston is located in Phoenix, 
note and is active. Therefore, when Boston receives the resource 
note request, it will create an OBPL and send it to Phoenix, which 
note re will then discard it. 

revem 


Control message number 12 representing a remote resource request 
has been received 
Resource not available, process remains blocked. 
Control message number ve sent from Boston to Phoenix 
representing an OBPL 
revem 13 
Control message number i r 
rqdbo exclusive Phoenix p2 Phoe 
Resource not available, process bloaked, 
Control message number 4 sent from Phoenix to Cambridge 
represencite an OBPL 
BPL will be discarded by Cambridge because p3, which controls 


sprecent tne an OBPL has been received. 
nix dbo1 


note The 
note dbo1 in Phoenix, is active. 
rovem 1 


Control message number 14 representing an OBPL has been received. 
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rqdbo exclusive Cambridge p3 Cambridge dbol 
Resource is not currently available for exclusive use, process p3 
at node Cambridge is blocked. 
Control message number 1 sent from Cambridge to Phoenix 
representing an OBPL 
note The OBPL will be discarded by Phoenix because pi, which controls 
note abot in Cambridge, is active. 
revem 15 
Control message number 15 representing an OBPL has been received. 
rqdbo shared camorage p2 Phoenix dbo 
Process p2 at node Cambridge is blocked while a request is sent to 
the node popves nine he desired resource 
Control message number 1 sent from Cambrid to Phoenix 
representing a remote resource reques 
revem 16 
Control message number 16 representing a remote resource request 
has been received 
Resource not available, process remains blocked. 
Control message number 17 sent from Phoenix to Cambridge 
‘ Peere reer ane an OBPL 
n 


note PL is sent to Cambridge because p3 in Cambridge controls 
note dbo1 in Phoenix. 3 will be added to the OBPL which will then 
note be ssed to Phoenix because p1 in Phoenix controls dbol in 
note + Cambridge. The OBPL will then be discarded because p1 is active. 
revem 
Control message number . representing an OBPL has been received. 
Control message number 1 sent from Cambridge to Phoenix 


representing an OBPL 


revem 18 

Control message number 18 representing an OBPL has been received. 
note The next request creates three deadlocks. When Boston receives 
note the remote resource request for dbo2, it creates three OBPL's 
note because there are three readers of the database object. We will 
note then allow the three OBPL's to be passed pg 3 nodes until all 
note three deadlocks have been detected, at which time there will be 
note no outstanding OBPL's or control messages. 


rqdbo exclusive Phoenix p1 Boston dbo2 
Process Pi at node Phoenix is blocked while a request is sent to 
he node containing the desired resource 
Control message number 19 sent from Phoenix to Boston 
19 representing a remote resource request 
revem 
Control message number 19 representing a remote resource request 
has been received 
Resource is not currently available for exclusive use, process p1 


at node Phoenix remains blocked 

Control message number 20 sent from Boston to Cambridge 
representing an OBPL 

Control message number 21 sent from Boston to Phoenix 
representing an OBPL 

Control message number 22 sent from Boston to Cambridge 


representing an OBPL 
revem 21 
Control message number 21 representing an OBPL has been received. 
A deadlock has been detected. The following processes are involved: 
pi at node hoenix 


pi at node Boston 
End of deadlock list 
revem 20 


Control message number 20 represent soe an OBPL has been received. 
Control message number 23 sent from Cambridge to Boston 
representing an OBPL 
revem 22 
Control message number St Sal pay bla an OBPL has been received. 
Control message number 2 sent from Cambridge to Phoenix 
representing an OBPL 
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revem 23 


Control message number 23 mepresenu ing an OBPL has been received. 
fe) 


Control message number 25 sent from ston to Phoenix 
representing an OBPL 


revem 25 


Control message number 2 representing an OBPL has been received. 


Control message number 2 sent from oenix to Cambridge 
representing an OBPL 


revem 26 


Control message number 26 representing an OBPL has been received. 
A deadlock has been detected. The Sh as fe het haa are involved: 


pi at node oenti 
pl at node Cambridge 
p2 at node Phoenix 


B3 at node Cambridge 
End of deadlock list 
revem 24 


Control message number 24 Seer eeee Bene OBPL has been received. 


Control message number 27 sent from oenix to Cambridge 
representing an OBPL 


revem 27 


Control message number 27 Reprecent Tne an OBPL has been received. 
A deadlock has been aerected: The forsee mooie are involved: 
pi 


at node oeni 
p2 at node Cambridge 


p3 at node Cambridge 
End of deadlock list 
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exclusive 


exclusive 


exclusive 


Phoenix 


1 
1 
J 
f 
shared 1 
| 


J 
exclusive ! 
! 


/Shared 


Cambridge 


Final State Diagram 
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scenario demo8 


note This is an example of a state where three deadlocks exist 

note ela six processes and five resources located in three 

note nodes. hree deadlocks are involved because dbo2 in Boston 

note has three shared users. Five, rather than six, resources are 
note involved because two processes are waiting for the same database 
note object. The first 18 commands create the state where all the 
note involved processes are active and all the involved resources 
note have been allocated to the proper processes. 


rqdbo shared Boston p1 Boston dbo2 
Pt at node Boston granted shared access to dbo2 at node Boston 
initmg mg1 Phoenix p1 Boston 
Message group mg has been initiated 
acceptmg mg1 Boston p1 
me has been accepted ah pi at node Boston 
rqdbo exclusive Phoenix pe oston dbo 
Process pe at node hoenix is blocked while a request is sent to 
he node containing the desired resource 
Control message number 1 sent from Phoenix to Boston 
representing a remote resource request 
revem 1 
Control message number 1 representing a remote resource request 
has been received 


p2 at.node Phoenix is granted exclusive use of 
dbol at node Boston 
Control message number 2 sent from Boston to Phoenix 


representing this allocation 
reven 
Control message number 2 representing a remote resource allocation 
has been received 
p2 at node Phoenix has been granted exclusive use of 
dbo at node Boston 
rqdbo shared Cambridge p1 Boston dbo2 
Process Pi at node Cambridge is blocked while a request is sent to 
he node containing the desired resource 
Control message number 3 sent from Cambridge to Boston 
3 representing a remote resource request 
revem 
Control message number 3 representing a remote resource request 
has been received 


p1 at node Cambridge is granted shared access to 
dbo2 at node Boston 
Control message number 4 sent from Boston to Cambridge 


4 representing this allocation 
revem 
Control message number 4 representing a remote resource allocation 
has been received 
pi at node Cambridge has been granted shared access to 
dbo2 at node Boston 
rqdbo shared aera. be p2 Boston dbo2 
Process 2 at node Cambridge is blocked while a request is sent to 
he node containing the desired resource 
Control message number 5 sent from Cambridge to Boston 
re pesent tng a remote resource request 
rqdbo shared Phoenix pi Cambridge dbo! 
Process P, at node Phoenix is blocked while a request is sent to 
he node containing the desired resource 
Control message number 6 sent from Phoenix to Cambridge 
representing a remote resource request 
revem 5 
Control message number 5 representing a remote resource request 
has been received 


p2 at node Cambridge is granted shared access to 
dbo2 at node Boston 
Control message number 7 sent from Boston to Cambridge 


representing this allocation 
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revem 6 
Control me eee ee number 6 representing a remote resource request 
has been received 
pl at node Phoenix is granted shared access to 
dbo1 at node Cambridge 
Control message number 8 sent from Cambridge to Phoenix 


1 representing this allocation 
revem 
Control message number 7 representing a remote resource allocation 
has been received 
p2 at node Cambridge has been granted shared access to 
dbo2 at node Boston 
revem 8 
Control message number 8 representing a remote resource allocation 
has been received 
pl at node Phoenix has been granted shared access to 
dbo at node Cambridge 
rqdbo exclusive Cambridge p3 Phoenix dbol 
Process p3 at node Cambridge is blocked while a request is sent to 
he node containing the desired resource 
Control message number 9 sent from Cambridge to Phoenix 
9 representing a remote resource request 
revem 
Control message number 9 representing a remote resource request 
has been received 


p3 at node Cambridge is granted exclusive use of 
dbo1 at node Phoenix 
Control message number 10 sent from Phoenix to Cambridge 


a representing this allocation 
revem 
Control message number 10 representing a remote resource allocation 
has been received 
p3 at node Cambridge has been granted exclusive use of 
at node Phoenix 
1 Boston dbo2 


dbo1 
rqdbo exclusive Phoenix 
hoenix is blocked while a request is sent to 


Process pl at node 
the node containing the desired resource 

Control message number 11 sent from Phoenix to Boston 
representing a remote resource request 


note After receipt of the remote resource request, Boston will send 
note two OBPL's to Cambridge because two processes in that node have 
note shared use of dbo2 in Boston. A third external message is not 
note needed because the third reader of dbo2 is located in Boston 
note and is active. We will delay the receipt of one of the OBPL's 
note until after the process in the list that controls dbo2 gets 
note re blocked waiting for a resource located in Phoenix. 

reven 


Control message number 11 representing a remote resource request 
has been received 
Resource is not currently available for exclusive use, process p1 


at node Phoenix remains blocke 

Control message number 12 sent from Boston to Cambridge 
representing an OBPL 

Control message number 13 sent from Boston to Cambridge 


representing an OBPL 
revem 12 
Control message number 12 representing an OBPL has been received. 
rqdbo shared Gambridee p1 Boston dbo1 
Process Pe at node Cambridge is blocked while a request is sent to 
he node containing the desired resource 
Control message number 14 sent from Cambridge to Boston 
representing a remote resource reques 
rqdbo shared Cambridge p2 Phoenix dbo1 
Process p2 at node Cambridge is blocked while a request is sent to 
the node containing the desired resource 
Control message number 15 sent from sepeatrs i to Phoenix 
representing a remote resource reques 
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revom 13 
Control message aveter FA representin n OBPL has been received. 
Control mt sent “25 285 dge Phoenix 
ret resen wie'e OBPL . 
note Let Phoenix receive, the: OBPL. beta e it receives. the remote resource 
note request that was assumed to have aken. Yi. aoe, be fore the last 
willbe. discarded because 


note was added to the OBPL.. ‘ 

note Phos oenix, has no record that p2 in a ridge is waiting for dbo! 

note in Phoenix. 

ie ee engage numbe Tepregenting an OBPL: hae be ived 
ontro Be yan. = rece ved. 

note the above: neal oned remote fetresouroe fo°es be received 

note bre Phoenix. An 0 i wali be be created - Cambridge, which 

note is 1, then discard Othe OBPL decause..p3. 18 act 

revcnm 


Control nessa are ‘pepresenting a remote . resource request 


Resource not. a R -b. 
Control nesnnne.. cae’ fron Ph ene to Cambridge 
representing. ty : 
revon 17 


Control me Dum representing. received. 
note Now le ciel request vor" doit 33 Sos ton by ted nd! soot 
note receiv 1LLde..: n 
note to where in. P ip welding? or..4 rats Paoenix 
note the Phoenix,” vker it hosnie is r here p3: 5 - 


passed 0 .. adtive an 

note _, the OBPL will then be discarded. ? 
revem 

Control moasage umber Lb re esenting: a ‘Penote ‘resource request 

as een received or a 
Resource not or cuewer 1 RBOseent fr bores blocked. 
Control mesons B oto Eneent* 
r 
pe oereae aT Sinha’ a ue » OBPL has b ived. 
ntrol | age. 8 sen an 8 been receive 
rqdbo rol notes hoen: oh street ae 
esource net availgdie,. aes blocked, 
Control message Sy Beant pete Phoenix to Cambridge 
. ream ag 

ucts 19 me BaF ei he discarded by. Cambridge. because p3 is active. 
reves 

Control message nuater 19° Pepresenting an OBPL has been. received. 
note The next command will oreat, Luo. two. Fr ree deadlock. 
note An OBPL wail be. gent Lo. ix, weich.will:s re iin Phoenix 
note to the OBPL and send the OBPL back. to: n- bet Buse, B- is waiting 
note for .dbo2 hat Lab, pred re two - 


Reston. deadla 
note OBPL*s watt Be" /oam sent “eo Cae ridge are , 
note oh Ponca at Ss ound un i ant ne 
note return to because 
note cambridge: Sete sage, be nobis’ ore oe Per get, examined. 
revms 
Petene = at node et is blocked waiting for a 


gepeeage group | 

Control message 2 sent gree’ Boston. to Phoenix 
age une an OBPL 

revem 20 


Control message number 20 renrepenetng, 20,08 OBPL has. _pasn secetyed. 


Control message number 21 sent. from oenix 
representing an OBPL 
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revem 21 
Control message number 21 representing an OBPL has been received. 
Control message number 22 sent from Boston to Cambridge 
re mesentsne an OBPL 
A deadlock has been detected. The following processes are involved: 
pi at node oston 
pl at node Phoenix 
End of deadlock list 
Control message number 2 sent from Boston to Cambridge 
representing an OBPL 
revem 22 
Control message number 22 representing an OBPL has been received. 
Control message number 24 sent from mbridge to Boston 
representing an OBPL 
revem 24 


Control message number 24 mepresenttne an OBPL has been received. 
Control message number 25 sent from Boston to Phoenix 
representing an OBPL 
revem 25 
Control message number 3? Pepresenttng an OBPL has been received. 
Control message number 2 sent from hoenix to Cambridge 
representing an OBPL 
revem 26 
Set message number 26 representing an OBPL has been received. 
revom 
Control message number 2 representing an OBPL has been received. 
Control message number 2 sent from Cambridge to Phoenix 
representing an OBPL 
revem 27 
Control message number 2h cepresentang an OBPL has been received. 
Control message number 2 sent from Phoenix to Cambridge 
representing an OBPL 


revem 28 

Control message number 28 representing an OBPL has been received. 
note This next request will create two deadlocks. An OBPL will be 
note sent to Phoenix, which will add pi in Phoenix to the list and 
note send it to Boston. Boston will then send out three OBPL'S, 
note one for each reader of dbo2 in Boston. These OBPL's will be 
note passed among the various nodes until there are no more OBPL's 
note and control messages oubetanese: Note that the two process two 
note resource deadlock will be detected for a second time because of 
note the fact that p1 in Boston still has shared access to dbo2 in 
etd Boston and the deadlock has not been broken by aborting any 
note rocesses, 


raqdbo exclusive Cambridge p3 Cambridge dbo1 
Resource is not currently available for exclusive use, process p3 
at node Cambridge is blocked. 
Control message number 2 sent from Cambridge to Phoenix 
representing an OBPL 
revem 29 
Control message number 2 representine an OBPL has been received. 
Control message number 3 sent from hoenix to Boston 
representing an OBPL 


revem 30 

Control message number 3$ weprepenting an OBPL has been received. 

Control message number 1 sent from Boston to Cambridge 
representing an OBPL 

Control message number 32 sent from Boston to Phoenix 
representing an OBPL 

Control message number 33 sent from Boston to Cambridge 
representing an OBPL 


revem 32 
Control message number 32 representing an OBPL has been received. 
A deadlock has been detected. The oer us | processes are involved: 
pi at node hoenix 
pi at node Boston 
End of deadlock list 
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revem 31 


Control message number 3] representing an OBPL has been received. 
Control message number 34 sent from Cambridge to Boston 
representing an OBPL 
revem 34 
Control message number 20 cepregsu. the an OBPL has been received. 
Control message number 35 sent from Boston to Phoenix 


representing an OBPL 
revem 35 
Control message number 35 representing an OBPL has been received. 
A deadlock has been sore The followi processes are involved: 


p at node ambridge 
pl at node Phoenix 
pi at node Cambridge 


p2 at node Phoenix 
End of deadlock list 
revem 33 


Control message number 3 represent +ng an OBPL has been received. 

Control message number sent from ambridge to Phoenix 
representing an OBPL 

revoem 36 
Control message number 36 representing an OBPL has been received. 
A deadlock has been detected. The Stated processes are involved: 

p3 at node anbridge 
pi at node Phoenix 


p2 at node Cambridge 
End of deadlock list 


171 


Appendix III scenario demo9 


scenario demo9 


note This is an example of a case where a process releases a remote 
note database object and sends a remote resource control pecente at 

note the same time that an OBPL is sent to this node stating that some 
note other process is waiting for the resource mentioned above, which 
note is controlled by the first process mentioned above. Before the 
note OBPL arrives, the first process gets blocked waiting for a resource 
note that is controlled by the process that was placed in the OBPL. 

note No deadlock is detected because the resource in question is no 
note longer controlled by the last process to be added to the OBPL. 
rqdbo shared Boston p1 Phoenix dbo1l 


Process Pp at node Boston is blocked while a request is sent to 
he node containing the desired resource 
Control message number 1 sent from Boston to Phoenix 
; representing a remote resource request 
revem 
Control message number 1 representing a remote resource request 
has been received 


pl at node Boston is granted shared access to 
dbo at node Phoenix 
Control message number 2 sent from Phoenix to Boston 


; representing this allocation 
revem 
Control message number 2 representing a remote resource allocation 
has been received 
p1 at node Boston has been granted shared access to 
dbo1 at node Phoenix 
radbo exclusive Phoenix Bi Boston dbo1 
Process Pe at node Phoenix is blocked while a request is sent to 
he node containing the desired resource 
Control message number 3 sent from Phoenix to Boston 
representing a remote resource request 


revem 3 
Control meseote number 3 representing a remote resource request 
has been received 
pt at node Phoenix is granted exclusive use of 
dbo1 at node Boston 
Control message number 4 sent from Boston to Phoenix 


P representing this allocation 
revem 
Control message number 4 representing a remote resource allocation 
has been received 
pi at node Phoenix has been granted exclusive use of 
dbo at node Boston 
rqdbo shared Boston p1 Boston dbol 
Resource not available, process blocked. 


Control message number sent from Boston to Phoenix 
representing an OBPL 
note Let dbol in Boston be released by p1 in Phoenix, and let p1 in 
note Phoenix then get blocked waiting for dbo! in Phoenix before the 
note OBPL from Boston is received by Phoenix. 


ridbo Phoenix p1 Boston dbo1 
Control message number 6 sent from Phoenix to Boston 
representing a remote resource release 
revem 6 
Control message number 6 representing a remote resource release 
has been received 


dbo1 at node Boston has been released by 
p at node Phoenix 

Process p1 at node Boston is granted shared access to 
dbo at node Boston 


rqdbo exclusive Phoenix p1 Phoenix dbo 
Resource is not currently available for exclusive use, process p1 
at node Phoenix is blocked. 
Control message number 7 sent from Phoenix to Boston 
representing an OBPL 
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revem 7 

Control message number 7 representing an OBPL has been received. 
note No deadlock will be detected because Phoenix observes that p1 in 
note Phoenix no longer has access to dbo1 in Boston, and discards 
note 5 the OBPL. 
revenm 


Control message number 5 representing an OBPL has been received. 


shared 


Boston Phoenix 


State where control message 5 has just been sent from Boston to Phoenix 


Control message 5 represents an OBPL. eceipt of the OBPL is delayed until : 
after the state drawn below is reached. 


shared 


@ 


shared 


Boston 


Phoenix 


Final State Diagram 
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scenario demo10 


note This is an example where an OBPL is sent from Boston to Phoenix 
note stating that a process in Boston is waiting for a message from a 
note process in Phoenix. Before the OBPL arrives in Phoenix, the 

note desired message is sent, and the process in Phoenix gets blocked 
note waiting for a resource that is controlled by the process that was 
note Placed in the OBPL that was sent from Boston to Phoenix. No 

note deadlock is detected because Phoenix notices that the message 
note that was desired by the process in Boston has alge been sent. 
nete The first six commands create the state where the OBPL 

note mentioned above has just been sent. 


initmg mg1 Phoenix p1 Boston 
Message group mgi has been initiated 
acech ns mg1 Boston pl 
mg has been accepted by P! at node Boston 
rqdbo exclusive Boston p1 Phoenix dbol 
Process pi at node Boston is blocked while a request is sent to 
the node containing the desired resource 
Control message number 1 sent from Boston to Phoenix 
; representing a remote resource request 
revem 
Control message number 1 representing a remote resource request 
has been received 


pi at node Boston is granted exclusive use of 
dbol at node Phoenix 
Control message number 2 sent from Phoenix to Boston 


‘ representing this allocation 
revem 
Control message number 2 representing a remote resource allocation 
has been received 


pl at node Boston has been granted exclusive use of 
dbol at node Phoenix 
revmsg mgz1 
Process’ pl at node Boston is blocked waiting for a 
message in message group mgi 
Control message number 3 sent from Boston to Phoenix 
representing an OBPL 
note We will now ide abr delay receipt of the OBPL by Phoenix. 
note Send the message that the process in Boston desires. 
sendmsg mg1 
Control message number 4 sent from Phoenix to Boston 
representing a message ina errors group 
note Let the process in Boston receive the message. 
revem 


Control message_number 4 representing a message in a message group 
has been received 


Process pi at node Boston has been awakened upon 
receipt of a message in mat group mail 
note Block p1 in Phoenix and then let Boston discard the OBPL that 
note will be created as a result of this wait. 


rqdbo shared Phoenix p1 Phoenix dbol 
Resource not available, process blocked. 
Control message number sent from Phoenix to Boston 
representing an OBPL 


revem 5 

Control measere number 5 poererent ane an OBPL has been received. 
hore noe le Phoenix receive the OBPL that was previously sent by 
note oston. 


revem 3 
Control message number 3 representing an OBPL has been received. 
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Boston 


Phoenix 


State where control message 3 representing an OBPL has ge been sent 
from Boston to Phoenix. Receipt of the OBPL is delayed until after the state 
drawn below is reached. 


exclusive shared 


Boston 


Phoenix 


Final State Diagram 
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scenario demo11 
note This is an example of a deadlock involving one process and one 
note operator at the same node. Two operator connections are involved. 
delop Boston opi 

op? has been declared as an operator at node Boston 
eopeen con! Boston opi p1 

perator connection conil has been established 
copcon con2 Boston op! p1 

erator connection con2 has been established 


note Let p1 in Boston request a message from operator op1 in Boston 
revopmsg con 
Process p1 at node Boston is blocked waiting for a 


message over operator connection con! 
An OBPL has been queued waiting for a status report from operator op1 


at node Boston The involved operator connection is con! 
note Create a deadlock by reporting that opi is waiting for a message 
note over operator connection con2. 


opstat Boston op1 hig hab con2 
We will now check for deadlock involving the given operator 
and operator connection 
A deadlock has been detected. The foraeeene processes are involved: 
pi at node oston 
op) at node Boston 
End of deadlock list 


Boston 


Final State Diagram 
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scenario demol2 


note This is an example of a deadlock across three nodes which involves 
note several operator connections. It demonstrates that deadlock 

note involving operators will be detected as long as the operator 

note property states what he is waiting for. The first 15 commands 
note set u he state where all operators have been declared, all 

note operator connections have been created, the message group has 

note been initiated and accepted, and the involved database objects 
note have been assigned to the proper processes. 


declop Boston op! 
op] has been declared as an operator at node Boston 
delop Phoenix op1 
op has been declared as an operator at node Phoenix 
dclop Boston op2 
op has been declared as an operator at node Boston 
eopeen con! Boston op! pl 
perator connection conl has been established 
copeon con2 Boston op! p2 
Operator connection con2 has been established 
eopeon con3 Boston op2 p2 
perator connection con3 has been established 
sopegn con4 Boston op2 p3 
perator connection con4 has been established 
copeon con5 Phoenix op! p2 
perator connection con as been establishe 
0 t ti 5 has bd tablished 
Gopeon con6 Phoenix op! p1 
erator connection con6 has been established 
initmg mg1 Cambridge p1 Phoenix 
Message group mg1 has been initiated 
acceptmg mg1 Phoenix p1 
mg has been accepted by Pi at node Phoenix 
rqdbo exclusive Boston p3 Cambridge dbo1 
Process 3 at node Boston is blocked while a request is sent to 
he node containing the desired resource 
Control message number 1 sent from Boston to Cambridge 
; representing a remote resource request 
revem 
Control message number 1 representing a remote resource request 
has been received : 


p3 at node Boston is granted exclusive use of 
dbol at node Cambridge 
Control message number 2 sent from Cambridge to Boston 


. representing this allocation 
reven 
Control message number 2 representing a remote resource allocation 
has been receive 
p3 at node Boston has been granted exclusive use of 
dbo1 at node Cambridge 
rqdbo shared Phoenix p2 Phoenix dbo! 
p2 at node Phoenix granted shared access to dbol at node Phoenix 


note Let p! in Boston wait for exclusive use of dbol in Phoenix. No 
note deadlock will be detected because p2 in Phoenix, which controls 
note dbol in Phoenix, is active. 


raqdbo exclusive Boston pi Phoenix dbo1 
Process Pp at node Boston is blocked while a request is sent to 
he node containing the desired resource 
Control] message number 3 sent from Boston to Phoenix 
representing a remote resource request 
revem 3 
Control meoocRe number 3 representing a remote resource request 
has been received 
Resource is not currently available for exclusive use, process pi 
at node Boston remains blocked 
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note Let pe in Phoenix now wait for a message from opi in Phoenix. 
note We then state that op! in Phoenix is active, so no OBPL's get 
note expanded further. 
revopmsg con5 

Process p2 at node Phoenix is blocked waiting for a 


message over operator connection con5 
An OBPL has been queued waiting for a status report from operator op! 
at node Phoenix The involved operator connection is con5 
opstat Phoenix opt active 
All OBPL's wai ig the given state information have been discarded 


note Let pi in oenix wait for a message from p1 in Cambridge. No 
note deadlock exists because p1 in Cambridge is active. 
revnsg mg! 

Process p1 at node Phoenix is blocked waiting for a 

message in message group mg 

Control message number 4 sent from Phoenix to Cambridge 

representing an OBPL 
revem 4 ; 

Control message number 4 representing an OBPL has been received. 
note Let p3 in Boston wait for a message from op2 in Boston. The 
note OBPL created when p3 gets blocked will be discarded when we 
note state that op2 is active. 
revopmsg con4 

Process p3 at node Boston is blocked waiting for a 


message over operator connection con4 
An OBPL has been queued waiting for a status report from operator op2 
at node Boston The involved operator connection is con 
opstat Boston op2 active 
All OBPL's waiting for the given state information have been discarded 


note Simultaneously block p1 in Cambridge ard p2 in Boston. Then 
note let Boston receive the OBPL from Cambridge that was created 
note when p1 in Cambridge was blocked. Before we report the status 
note of op! in Boston, state that op2 in Boston is waiting for a 
note message from p2 dn Boston, thereby queuing a second OBPL for 


note information on the status of opi in Boston. 
radbo shared Cambridge pi Cambridge dbol 
Resource not available, process blocked. 
Control message number sent from Cambridge to Boston 
representing an OBPL 
revopmsg con2 
Process p2 at node Boston is blocked waiting for a 
message over operator connection con2 
An OBPL has been queued waiting for a status report from operator op! 
5 at node Boston The involved operator connection is con2 
revem 
Control message number 5 representing an OBPL has been received. 
An OBPL has been queued waiting for a status report from operator op2 
at node Boston The involved operator connection is con 
opstat Boston ope Nia con3 
We will now check for deadlock involving the given operator 
and operator connection 
An OBPL has been queued waiting for a status report from operator op! 
at node Boston The involved operator connection is con2 
opstat Boston op! yee ene con 
We will now check for deadlock involving the given operator 
and operator connection 


Control message number 6 sent from Boston to Phoenix 
representing an OBPL 
Control message number 7 sent from Boston to Phoenix 
representing an OBPL 
note There were two OBPL's waiting for state information from op1 in 
note Boston, therefore two OBPL's are expanded and sent to Phoenix. 
note Let Phoenix receive and expand both OBPL's, and state that op1 
note in Phoenix is waiting for a message from pi in Phoenix, thereby 
note closing the deadlock loop. The deadlock will be detected twice 
note because we had two OBPL's being passed around due to the fact 
note that we blocked two processes simultaneously. 
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Appendix III scenario demotl2 


revem 6 
Control message number 6 representing an OBPL has been received. 
An OBPL has been queued waiting for a status report from operator op! 
7 at node Phoenix The involved operator connection is con5 
revem 
Control message number 7 representing an OBPL has been received. 
An OBPL has been queved waiting for a status report from operator op! 
at node Phoenix The involved operator connection is con5 
opstat Phoenix op! waiting con6 
We will now check for deadlock involving the given operator 
and operator connection 


Control message number 8 sent from Phoenix to Cambridge 
representing an OBPL 
Control message number 9 sent from Phoenix to Cambridge 
representing an OBPL 
revem 8 
Control message number 8 representing an OBPL has been received. 
Control message number 10 sent from Cambridge to Boston 
5 representing an OBPL 
revem 


Control message number 9 gl adh rcpraay an OBPL has been received. 
A deadlock has been detected. The fol ovine processes are involved: 
a 


p1 at node mbridge 
p3 at node Boston 
op2 at node Boston 
D. at node Boston 
op! at node Boston 
p at node Boston 
p2 at node Phoenix 
op! at node Phoenix 


pl at node Phoenix 
End of deadlock list 
revem 10 


Control message number 10 represent tne an OBPL has been received. 
An OBPL has been queued waiting for a status report from operator op2 
at node Boston The involved operator connection is con4 
opstat Boston op2 waiti con3 
We will now check for deadlock involving the given operator 
and operator connection 
A deadlock has been geueered: The ee processes are involved: 
fo) 


p at node ston 
op1 at node Boston 

pl at node Boston 

p2 at node Phoenix 
op! at node Phoenix 
pl at node Phoenix 
pi at node Cambridge 
p3 at node Boston 


ope at node Boston 
End of deadlock list 
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Appendix IIT ; soenario demol2 


Boston 


exclusive 


Cambridge 


Final State Diagram 
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